This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: debugging shared libraries
Jim Blandy wrote:
One of the problems here is that, technically, we don't know which
shared library the dynamic linker will actually load until the program
starts running, so we can't offer completion on its symbols.
Hi Jim,
But my original suggestion was about trying to sidestep that. If gdb is
run on the shared library, it's clear even technically what library we're
trying to debug! And indeed that already works fine (on ELF at least):
% gdb y.so
GNU gdb 6.4-debian
[..]
(gdb) break m<TAB>
mbstate_t my_buggy_shared_library_function()
(gdb) break my_buggy_shared_library_function()
Breakpoint 1 at 0x792: file y.cpp, line 5.
The only problem that I can see is that within gdb you can't start
a different executable.
That is, most probably I have a main program, maybe just:
main() { my_buggy_shared_library_function() }
which I don't need to debug - I only need to use that executable
to get the process started.
(gdb) file y.so
Reading symbols from /home/ajrh/y.so...done.
Using host libthread_db library "/lib/tls/libthread_db.so.1".
(gdb) break y.cpp:5
Breakpoint 1 at 0x792: file y.cpp, line 5.
(gdb) execute my_main_program
Undefined command: "execute". Try "help".
<oh well...>
We could try to guess what the dynamic linker was going to do, but
that's kind of a mess.
Oh agreed, it's difficult if one tried to anticipate symbol
definitions by chasing them from the main executable. That's why I'm
suggesting something orthogonal: the programmer identifies the shared
library to be debugged. But gdb currently seems a bit fixated on
the idea that the debug target must be the executable object file,
rather than one of the shared object files.
Rgds
Anthony