Re: debugging shared libraries

[Anthony Heading <ajrh at ajrh dot net>]

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