Hello,
(This is a lengthy post. I apologize, but wanted to be thorough)
In my never-ending battle with the xalan and xerces port, I have been
getting
many ‘?? in ()’ while in gdb. Of course, I have all -g flags complied in
but still never
saw any function calls. I have even tried the ‘shared’ feature of gdb trying
to get the
standard libs to load and those will not.
I found something interesting on Friday (I thought it was interesting).
I wanted to look at the debugging information in the .so with:
objdump -g libxerces-c1_6_0.so
libxerces-c1_6_0.so: file format elf32-i386
objdump: libxerces-c1_6_0.so: no recognized debugging information
So, I decided to dump the section headers of the .so and got:
objdump -h libxerces-c1_6_0.so
27 .debug 00f13a3c 00000000 00000000 00383054 22
CONTENTS, READONLY, DEBUGGING
28 .line 0005edf4 00000000 00000000 01296a90 20
CONTENTS, READONLY, DEBUGGING
29 .debug_srcinfo 000025d4 00000000 00000000 012f5884 20
CONTENTS, READONLY, DEBUGGING
30 .debug_sfnames 00002d40 00000000 00000000 012f7e58 20
CONTENTS, READONLY, DEBUGGING
31 .debug_aranges 00004934 00000000 00000000 012fab98 20
CONTENTS, READONLY, DEBUGGING
32 .debug_pubnames 0003db64 00000000 00000000 012ff4cc 20
CONTENTS, READONLY, DEBUGGING
… so, here’s a gdb session output:
./testme
Memory fault (core dumped)
gdb testme
GNU gdb 5.0 (UI_OUT)
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type “show copying” to see the conditions.
There is absolutely no warranty for GDB. Type “show warranty” for details.
This GDB was configured as “–host=x86-pc-nto-qnx --target=ntox86”…
(gdb) r
Starting program: /opt/xe/samples/kmc/testme
(gdb) c
Continuing.
Program received signal SIGSEGV, Segmentation fault.
0xb032bd7b in ?? ()
(gdb) bt
#0 0xb032bd7b in ?? ()
#1 0xb032becb in ?? ()
#2 0xb032ad2a in ?? ()
(gdb) shared
(gdb)
(note: nothing loaded … also note that there aren’t even library
identifiers)
And when I link this .so with a simple hello world program I still can’t see
any
debugging symbols for the function calls, etc.
So, I was thinking maybe I can’t see the debug symbols because it’s
unrecognized by objdmp?? Not so, because I do the same thing with a simple
hello world program that I force to core dump (and not linked with
libxerces-c1_6_0.so) and I can get at all the debug symbols and even the
standard library function calls show up using the ‘shared’ (gdb) feature.
And the output from objdump for the hello world program is very similar to
output from libxerces-c1_6_0.so.
Here’s the simple hello world program’s objdump -g output.
objdump -g testme.o
testme.o: file format elf32-i386
objdump: testme.o: no recognized debugging information
#objdump -h testme.o
5 .debug_sfnames 00000020 00000000 00000000 000000ec 20
CONTENTS, READONLY, DEBUGGING
6 .line 00000080 00000000 00000000 0000010c 20
CONTENTS, RELOC, READONLY, DEBUGGING
7 .debug_srcinfo 00000024 00000000 00000000 0000018c 20
CONTENTS, RELOC, READONLY, DEBUGGING
8 .debug_pubnames 0000001c 00000000 00000000 000001b0 20
CONTENTS, RELOC, READONLY, DEBUGGING
9 .debug_aranges 0000002c 00000000 00000000 000001cc 20
CONTENTS, RELOC, READONLY, DEBUGGING
10 .debug 0000a16c 00000000 00000000 000001f8 22
yet, here’s the big difference.
./testme
Memory fault (core dumped)
gdb testme
GNU gdb 5.0 (UI_OUT)
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type “show copying” to see the conditions.
There is absolutely no warranty for GDB. Type “show warranty” for details.
This GDB was configured as “–host=x86-pc-nto-qnx --target=ntox86”…
(gdb) r
Starting program: /opt/xe/samples/kmc/testme
(gdb) c
Continuing.
Program received signal SIGSEGV, Segmentation fault.
0xb033b1f1 in ?? () from /x86/lib/libc.so.2
(gdb) bt
#0 0xb033b1f1 in ?? () from /x86/lib/libc.so.2
#1 0xb03380fa in ?? () from /x86/lib/libc.so.2
#2 0xb03371f9 in ?? () from /x86/lib/libc.so.2
#3 0xb03347f2 in ?? () from /x86/lib/libc.so.2
#4 0x0804863a in main () at testme.cpp:24
(gdb) shared
Reading symbols from /x86/lib/libstdc++.so.2.2.10.0…done.
Reading symbols from /x86/lib/libm.so.2…done.
Reading symbols from /x86/lib/libc.so.2…done.
(gdb) bt
#0 0xb033b1f1 in memcpy () from /x86/lib/libc.so.2
#1 0xb03380fa in _Sprout () from /x86/lib/libc.so.2
#2 0xb03371f9 in _Printf () from /x86/lib/libc.so.2
#3 0xb03347f2 in sprintf () from /x86/lib/libc.so.2
#4 0x0804863a in main () at testme.cpp:24
(gdb)
– notice right away that i now see a ‘from /x86/…so’ line also and of
course the
libc function calls show up now, this is never seen from the same hello
world program that is linked with libxerces-c1_6_0.so.
For some reason, when I link in this libxerces-c1_6_0.so to the same hello
world program,
I lose all debugging symbols and library references on everything.
Thanks for reading this long post and I welcome all feedback.
I guess my obvious question is why objdump can’t recognize the debugging
information, yet
can still display it in gdb for the simple hello world program but
completely freaks when I link in the libxerces-c1_6_0.so?
Also, where do the symbols disappear to when i link with libxerces-c1_6_0.so
TIA,
Kevin