This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
debugging shared libraries
- From: Anthony Heading <ajrh at ajrh dot net>
- To: gdb at sources dot redhat dot com
- Date: Thu, 05 Jan 2006 09:11:43 -0500
- Subject: debugging shared libraries
Hello,
Happy New Year to all.
I know this is an old question, but (probably in a bout of
fresh New Year optimism) I hopefully tried the following:
~% gdb y.so
GNU gdb 6.4-debian
Copyright 2005 Free Software Foundation, Inc.
[...]
(gdb) break my_buggy_shared_library_function()
Breakpoint 1 at 0x792: file y.cpp, line 5.
(gdb) run my_executable
Starting program: /home/ajrh/y.so my_executable
Breakpoint 1 at 0x80000792: file y.cpp, line 5.
warning: shared library handler failed to enable breakpoint
Command syntax aside, can GDB really not DWIM? Starting
GDB on the .so seems like the right thing to do: the
tab-completion etc on the function names works to
get breakpoints set up, etc. But if the debug target is a
shared library then I probably need to run a different
executable to get the process started.
(gdb) help file
Use FILE as program to be debugged.
It is read for its symbols, for getting the contents of pure memory,
and it is the program executed when you use the `run' command.
Equivalently, I think, do these two properties really need
to be hardwired together?
For reference, I think this works to my gratification in
MS Visual Studio on Win32: if you try to debug a DLL, the
program prompts to ask which executable you'd like to start.
Regards
Anthony