RE: debugging shared libraries

RE: debugging shared libraries

[Kris Warkentin]

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
> 

Re: debugging shared libraries

[Anthony Heading]

Hi Kris,

Kris Warkentin wrote:
> GDB has support for deferred breakpoints.  Try:
 > [...]

Yup, I know about that.

The problem I see, as I tried to allude to but maybe didn't
make clear, is e.g. that tab-completion of the breakpoint symbol
obviously doesn't work.  And although that might not seem
a major problem, I assumed that made it very difficult for the
GUI front ends to gdb (kdbg / eclipse / whatever) to be started
against a shared library.  (Which is my real ideal).

Though I guess thinking about it, maybe a GUI front end could
load the shared lib, let you identify the breakpoint, and then
behind the scenes save the name of the breakpoint symbol, load
the main executable and set it as a deferred breakpoint.  Do
any of the GUIs do that?

Rgds

Anthony

Re: debugging shared libraries

[Jim Blandy]

On 1/5/06, Anthony Heading <ajrh@ajrh.net> wrote:
> The problem I see, as I tried to allude to but maybe didn't
> make clear, is e.g. that tab-completion of the breakpoint symbol
> obviously doesn't work.  And although that might not seem
> a major problem, I assumed that made it very difficult for the
> GUI front ends to gdb (kdbg / eclipse / whatever) to be started
> against a shared library.  (Which is my real ideal).

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.  We could
try to guess what the dynamic linker was going to do, but that's kind
of a mess.

Re: debugging shared libraries

[Anthony Heading]

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

Re: debugging shared libraries

[Jim Blandy]

On 1/6/06, Anthony Heading <ajrh@ajrh.net> wrote:
> 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):

(That's what I get for jumping into the middle of a thread.)

You're right, there's no necessary connection there that I can see.

You'll need to make sure the breakpoints get disabled
(bp_shlib_disabled) and re-set (as by breakpoint_re_set), since the
shared library probably won't get loaded at the address GDB expects
before the program runs.

debugging shared libraries

[Anthony Heading]

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