RE: debugging shared libraries

[Kris Warkentin <KEWarken@qnx.com>]

Hi Anthony,

GDB has support for deferred breakpoints.  Try:

gdb my_executable

(gdb) break my_buggy_shared_library_function()
(gdb) blah blah not found would you like to defer this? y
(gdb) r

Then gdb loads the shared libraries (based on information in the runtime
image of the executable) and sets the breakpoint.

That should work.

cheers,

Kris

> -----Original Message-----
> From: gdb-owner@sourceware.org 
> [mailto:gdb-owner@sourceware.org] On Behalf Of Anthony Heading
> Sent: Thursday, January 05, 2006 9:12 AM
> To: gdb@sources.redhat.com
> 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
>