.gdbinit, Lisp_Type_Char, and DWARF-2 vs. stabs

[Jerry James]

Moving the discussion to xemacs-beta...

Malcolm Purvis <malcolmp at xemacs.org> wrote:
> Unrelated to these changes, but on the topic of .gdbinit, does anyone else
> have problems with gdb define 'pobj'?  Whenever I try and use it I get the
> following:
>
> (gdb) pobj Qnil
> No symbol "Lisp_Type_Char" in current context.

Yes, darn it.  What gcc are you using?  I'm running Fedora Core 5, and
have gcc-4.1.0-3 from that distribution.  If I dump debug information
from the compiled XEmacs binary with either "readelf -w" or "objdump -W"
and then grep for Lisp_Type_Char, all I see are uses.  There is no
definition in there.  This is using the portable dumper.  The default
debug format for both platforms I use (i386 and x86_64, big difference
hey?) is DWARF-2, which is supposed to be the most expressive.  I even
habitually compile with -g3 to pick up macro definitions, and I still
don't get the Lisp_Type_Char debug info.

If I compile with "-gstabs+", then "objdump -G" shows me this:

333    LSYM   0      0      00000000 14127  Lisp_Type:T(12,70)=eLisp_Type_Record:0,Lisp_Type_Int_Even:1,Lisp_Type_Char:2,Lisp_Type_Int_Odd:3,;

328520 LSYM   0      0      00000000 997931 Lisp_Type:T(22,70)=eLisp_Type_Record:0,Lisp_Type_Int_Even:1,Lisp_Type_Char:2,Lisp_Type_Int_Odd:3,;

And sure enough, now pobj works.  Like I said, I'm using the portable
dumper, but I'm also using mc-alloc, so I get a separate dump file.
That means that my xemacs executable is the one produced by gcc, not one
we fiddled with, right?  If so, this can only be a gcc bug.

Also notice the difference in size between the two executables.  The
DWARF-2 version weighs in at 46,484,008 bytes for this morning's build,
while the stabs version is 9,617,276 bytes.  Compiling with
-feliminate-dwarf2-dups would probably help, at some compile or link
time cost.  On the other hand, I also did not use
-feliminate-unused-debug-symbols on the stabs build.

I see gcc 4.1.1 came out yesterday.  I probably won't have time to try
it myself, but we should see if the problem persists with that version.
If so, it's time to ask for help from the fine gcc development team.
-- 
Jerry James, Assistant Professor        james at xemacs.org
Computer Science Department             http://www.cs.usu.edu/~jerry/
Utah State University