bug#12036: 24.1.50; xvectype and xpr broken by change in PVEC_TYPE_MASK when macro information not available

bug#12036: 24.1.50; xvectype and xpr broken by change in PVEC_TYPE_MASK when macro information not available

[Eli Zaretskii]

This bug report will be sent to the Bug-GNU-Emacs mailing list
and the GNU bug tracker at debbugs.gnu.org.  Please check that
the From: line contains a valid email address.  After a delay of up
to one day, you should receive an acknowledgement at that address.

Please write in English if possible, as the Emacs maintainers
usually do not have translators for other languages.

Please describe exactly what actions triggered the bug, and
the precise symptoms of the bug.  If you can, give a recipe
starting from `emacs -Q':

 cd src
 gdb ./emacs
 (gdb) break decode_any_window
 (gdb) r -Q
 Breakpoint 3, decode_any_window (window=54912845) at window.c:149
 149       if (NILP (window))
 (gdb) n
 152       CHECK_WINDOW (window);
 (gdb) p window
 $1 = 54912845
 (gdb) xtype
 Lisp_Vectorlike
 No symbol "PVEC_TYPE_MASK" in current context.

AFAICS, this happens because PVEC_TYPE_MASK is now a macro, whereas it
was an enumerated type before.  Therefore, any GDB commands that use
it will not work unless the macro information is available to GDB,
which only happens with some GCC switches.

Please make these commands work without requiring -g3 again.

If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.
For information about debugging Emacs, please read the file
d:/gnu/bzr/emacs/trunk/etc/DEBUG.


In GNU Emacs 24.1.50.1 (i386-mingw-nt5.1.2600)
 of 2012-07-23 on HOME-C4E4A596F7
Bzr revision: 109194 eliz@gnu.org-20120723165720-qecdk4kza6po0al7
Windowing system distributor `Microsoft Corp.', version 5.1.2600
Configured using:
 `configure --with-gcc (3.4) --no-opt --enable-checking --cflags
 -Id:/usr/include/libxml2 -DGLYPH_DEBUG=1'

Important settings:
  value of $EMACSDATA: D:/gnu/bzr/emacs/trunk/etc
  value of $EMACSDOC: D:/gnu/bzr/emacs/trunk/etc
  value of $EMACSLOADPATH: D:/gnu/bzr/emacs/trunk/lisp;D:/gnu/bzr/emacs/trunk/leim
  value of $EMACSPATH: D:/gnu/bzr/emacs/trunk/bin
  value of $LANG: ENU
  locale-coding-system: cp1255
  default enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
M-x r e p o r t - e m <tab> <return>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils time-date tooltip ediff-hook vc-hooks
lisp-float-type mwheel dos-w32 disp-table ls-lisp w32-win w32-vars
tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment
lisp-mode register page menu-bar rfn-eshadow timer select scroll-bar
mouse jit-lock font-lock syntax facemenu font-core frame cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev
minibuffer button faces cus-face files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote make-network-process multi-tty emacs)

bug#12036: 24.1.50; xvectype and xpr broken by change in PVEC_TYPE_MASK when macro information not available

[Paul Eggert]

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.

bug#12036: 24.1.50; xvectype and xpr broken by change in PVEC_TYPE_MASK when macro information not available

[Eli Zaretskii]

> 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.  <<<<<<<<<<<<<<<

bug#12036: 24.1.50; xvectype and xpr broken by change in PVEC_TYPE_MASK when macro information not available

[Eli Zaretskii]

> 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

[Paul Eggert]

Thanks, I didn't run into those problems since I tested
by debugging when the symbols happened to be in scope.

I reproduced some of the problems and installed a fix as
trunk bzr 109219.

However, there's one thing I couldn't reproduce:

On 07/26/2012 11:03 AM, Eli Zaretskii wrote:
>   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.

I expect that I don't have this problem because the bug has been fixed
in my tools (GCC 4.7.1 + GDB 7.4.1).  I tried to work around the problem
by putting this line into lisp.h:

PUBLISH_TO_GDB ((enum pvec_type) 0);  /* This also publishes PVEC_*.  */

but I can't easily test this, since my tools don't have the problem.
Could you please try it?  And if it doesn't work, could you
please try adding lines like this:

PUBLISH_TO_GDB (PVEC_TYPE_MASK);

for values like PVEC_TYPE_MASK that do not otherwise work for you?
Thanks.

bug#12036: 24.1.50; xvectype and xpr broken by change in PVEC_TYPE_MASK when macro information not available

[Eli Zaretskii]

> Date: Thu, 26 Jul 2012 11:46:08 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: 12036@debbugs.gnu.org
> 
> >   (gdb) xtype
> >   Lisp_Vectorlike
> >   No enum type named pvec_type.
> 
> I expect that I don't have this problem because the bug has been fixed
> in my tools (GCC 4.7.1 + GDB 7.4.1).  I tried to work around the problem
> by putting this line into lisp.h:
> 
> PUBLISH_TO_GDB ((enum pvec_type) 0);  /* This also publishes PVEC_*.  */
> 
> but I can't easily test this, since my tools don't have the problem.
> Could you please try it?  And if it doesn't work, could you
> please try adding lines like this:
> 
> PUBLISH_TO_GDB (PVEC_TYPE_MASK);
> 
> for values like PVEC_TYPE_MASK that do not otherwise work for you?

Unfortunately, with my ancient version of GCC, I don't even get past
CHECK_LISP_OBJECT_TYPE in xgetptr:

  .gdbinit:1197: Error in sourced command file:
  No symbol "CHECK_LISP_OBJECT_TYPE" in current context.

Looks like PUBLISH_TO_GDB is not doing the trick here.

Anyway, with tricky macros such as PUBLISH_TO_GDB, I'd think that
going back to using variables whose type is the enum would be better,
don't you think?  We could modify PUBLISH_TO_GDB to do that.

bug#12036: 24.1.50; xvectype and xpr broken by change in PVEC_TYPE_MASK when macro information not available

[Paul Eggert]

On 07/26/2012 01:10 PM, Eli Zaretskii wrote:
> Anyway, with tricky macros such as PUBLISH_TO_GDB, I'd think that
> going back to using variables whose type is the enum would be better,

Yes, that's right.  Unfortunately this can't be encapsulated as nicely
as PUBLISH_TO_GDB can, so I reverted the PUBLISH_TO_GDB business
and went back to the old way of making enums visible, in
trunk bzr 109224.  Please give it a try.

bug#12036: 24.1.50; xvectype and xpr broken by change in PVEC_TYPE_MASK when macro information not available

[Eli Zaretskii]

> Date: Thu, 26 Jul 2012 23:22:40 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: 12036@debbugs.gnu.org
> 
> On 07/26/2012 01:10 PM, Eli Zaretskii wrote:
> > Anyway, with tricky macros such as PUBLISH_TO_GDB, I'd think that
> > going back to using variables whose type is the enum would be better,
> 
> Yes, that's right.  Unfortunately this can't be encapsulated as nicely
> as PUBLISH_TO_GDB can, so I reverted the PUBLISH_TO_GDB business
> and went back to the old way of making enums visible, in
> trunk bzr 109224.  Please give it a try.

Thanks, it seems to work now, at least in a few simple tests I ran
here.  However, there's still a small nuisance:

  (gdb) break decode_any_window
  Breakpoint 3 at 0x11de2a8: file window.c, line 149.
  (gdb) r -Q
  Starting program: D:\gnu\bzr\emacs\trunk\src/./oo/i386/emacs.exe -Q
  [New Thread 1452.0x15d4]

  Breakpoint 3, decode_any_window (window=54896461) at window.c:149
  149       if (NILP (window))
  (gdb) n
  152       CHECK_WINDOW (window);
  (gdb) p window
  $1 = 54896461
  (gdb) xtype
  Lisp_Vectorlike
  262144          <<<<<<<<<<<<<<<<<<<<<<

In Emacs 24.1, it does better:

  (gdb) p window
  $1 = 53340677
  (gdb) xtype
  Lisp_Vectorlike
  PVEC_WINDOW

I'm not sure if it will be better to go back to 24.1 behavior and
display PVEC_WINDOW, or change .gdbinit to say something more explicit
and human-readable here, such as "window" (and similarly for other
vector-like types).

bug#12036: 24.1.50; xvectype and xpr broken by change in PVEC_TYPE_MASK when macro information not available

[Paul Eggert]

On 07/27/2012 02:40 AM, Eli Zaretskii wrote:
> I'm not sure if it will be better to go back to 24.1 behavior and
> display PVEC_WINDOW

That's easier; all we need to do is fix .gdbinit to reflect
the pvec_type changes that were installed on July 4.
I did that, as trunk bzr 109240; please give it a try.

bug#12036: 24.1.50; xvectype and xpr broken by change in PVEC_TYPE_MASK when macro information not available

[Eli Zaretskii]

> Date: Fri, 27 Jul 2012 13:51:30 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: 12036@debbugs.gnu.org
> 
> On 07/27/2012 02:40 AM, Eli Zaretskii wrote:
> > I'm not sure if it will be better to go back to 24.1 behavior and
> > display PVEC_WINDOW
> 
> That's easier; all we need to do is fix .gdbinit to reflect
> the pvec_type changes that were installed on July 4.
> I did that, as trunk bzr 109240; please give it a try.

Thanks, it works fine now.