This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]