[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#12036: 24.1.50; xvectype and xpr broken by change in PVEC_TYPE_MASK
From: |
Eli Zaretskii |
Subject: |
bug#12036: 24.1.50; xvectype and xpr broken by change in PVEC_TYPE_MASK when macro information not available |
Date: |
Thu, 26 Jul 2012 21:03:24 +0300 |
> Date: Thu, 26 Jul 2012 19:56:31 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 12036@debbugs.gnu.org
>
> > Date: Thu, 26 Jul 2012 02:14:54 -0700
> > From: Paul Eggert <eggert@cs.ucla.edu>
> >
> > I ran into this problem independently and fixed it in
> > trunk bzr 109213. I just now found this bug report and
> > am marking it as done.
>
> Thanks, but it doesn't appear to be entirely fixed. Somehow, the
> CHECK_LISP_OBJECT_TYPE thing is unknown to GDB:
>
> D:\gnu\bzr\emacs\trunk\src>gdb ./oo/i386/emacs.exe
> GNU gdb (GDB) 7.4.1
> Copyright (C) 2012 Free Software Foundation, Inc.
> [...]
> .gdbinit:1197: Error in sourced command file:
> No symbol "CHECK_LISP_OBJECT_TYPE" in current context. <<<<<<<<<<<<<<<<
> (gdb) break decode_any_window
> Breakpoint 1 at 0x11de1b8: file window.c, line 149.
> (gdb) r -Q
> Starting program: D:\gnu\bzr\emacs\trunk\src/./oo/i386/emacs.exe -Q
> [New Thread 5748.0xa3c]
>
> Breakpoint 1, decode_any_window (window=54888269) at window.c:149
> 149 if (NILP (window))
> (gdb) n
> 152 CHECK_WINDOW (window);
> (gdb) p window
> $1 = 54888269
> (gdb) xtype
> No symbol "CHECK_LISP_OBJECT_TYPE" in current context. <<<<<<<<<<<<<<<
It looks like the enum values are known to GDB only if there's a
variable which has that enum type. E.g., if I change the enum like
this:
enum
{
CHECK_LISP_OBJECT_TYPE = gdb_CHECK_LISP_OBJECT_TYPE,
DATA_SEG_BITS = gdb_DATA_SEG_BITS,
GCTYPEBITS = gdb_GCTYPEBITS,
USE_LSB_TAG = gdb_USE_LSB_TAG
} foo;
then there's no problem with CHECK_LISP_OBJECT_TYPE. However, the
next problem in line is with VALBITS:
(gdb) break decode_any_window
Breakpoint 3 at 0x11de1b8: file window.c, line 149.
(gdb) r -Q
Starting program: D:\gnu\bzr\emacs\trunk\src/./oo/i386/emacs.exe -Q
[New Thread 5144.0xe24]
Breakpoint 3, decode_any_window (window=54888269) at window.c:149
149 if (NILP (window))
(gdb) n
152 CHECK_WINDOW (window);
(gdb) p window
$1 = 54888269
(gdb) xtype
No symbol "VALBITS" in current context.
This is again because no variable uses this enum:
enum { VALBITS = BITS_PER_EMACS_INT - GCTYPEBITS };
If I declare a variable with this enum, I get past VALBITS, but then
bump into pvec_type:
Breakpoint 3, decode_any_window (window=54888269) at window.c:149
149 if (NILP (window))
(gdb) n
152 CHECK_WINDOW (window);
(gdb) p window
$1 = 54888269
(gdb) xtype
Lisp_Vectorlike
No enum type named pvec_type.
Etc., etc.
The old code had real variables that used the enumerated types.
- bug#12036: 24.1.50; xvectype and xpr broken by change in PVEC_TYPE_MASK when macro information not available, Eli Zaretskii, 2012/07/23
- bug#12036: 24.1.50; xvectype and xpr broken by change in PVEC_TYPE_MASK when macro information not available, Paul Eggert, 2012/07/26
- bug#12036: 24.1.50; xvectype and xpr broken by change in PVEC_TYPE_MASK when macro information not available, Eli Zaretskii, 2012/07/26
- bug#12036: 24.1.50; xvectype and xpr broken by change in PVEC_TYPE_MASK when macro information not available,
Eli Zaretskii <=
- bug#12036: 24.1.50; xvectype and xpr broken by change in PVEC_TYPE_MASK when macro information not available, Paul Eggert, 2012/07/26
- bug#12036: 24.1.50; xvectype and xpr broken by change in PVEC_TYPE_MASK when macro information not available, Eli Zaretskii, 2012/07/26
- bug#12036: 24.1.50; xvectype and xpr broken by change in PVEC_TYPE_MASK when macro information not available, Paul Eggert, 2012/07/27
- bug#12036: 24.1.50; xvectype and xpr broken by change in PVEC_TYPE_MASK when macro information not available, Eli Zaretskii, 2012/07/27
- bug#12036: 24.1.50; xvectype and xpr broken by change in PVEC_TYPE_MASK when macro information not available, Paul Eggert, 2012/07/27
- bug#12036: 24.1.50; xvectype and xpr broken by change in PVEC_TYPE_MASK when macro information not available, Eli Zaretskii, 2012/07/28