Moving the discussion to xemacs-beta...
Malcolm Purvis <malcolmp(a)xemacs.org> wrote:
Unrelated to these changes, but on the topic of .gdbinit, does anyone
have problems with gdb define 'pobj'? Whenever I try and use it I get the
(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
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
328520 LSYM 0 0 00000000 997931
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(a)xemacs.org
Computer Science Department http://www.cs.usu.edu/~jerry/
Utah State University