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

Moving the discussion to xemacs-beta... Malcolm Purvis <malcolmp(a)xemacs.org&gt; wrote: 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(a)xemacs.org Computer Science Department http://www.cs.usu.edu/~jerry/ Utah State University