GDB and shared libraries

[Stephen Smith]

Ok, my code shipment went out the other day, so I am back on this topic.  Since this is the first time I have ever
modified GNU code, you may have to bear with me.

For the record, I have read Section 13 of the gdb manual (especially the section on the q packet).  I also read my gdb
server
code, and kevin's solib-svr4.h and solib-svr4.c files. from the 20010306 snapshot.

First a couple of questions:
    1)  Andrew:  you state that "Most shared library implementations can, in theory, be debugged remotely
         without any modifications to the GDB remote protocol."  But, if kevin is correct, the q packet will have to
         have some additional features added.  Correct?
    2)  I am planning on adding a solib-remote-elf.h and solib-remote-elf.c files.
         where should I add the hooks in the rest of the files - I don't see where the svr4 stuff is hooked in and I haven't

         figured out where to hook into remote communications code for modifying the q packet (if I do have to modify the
protocol).

Thanks for helping the newbie.
sps

Below is the summary of the current discussion, just so we don't have to go over it.

>  Andrew Cagney
>  Just FYI.
>
>  Most shared library implementations can, in theory, be debugged remotely
>  without any modifications to the GDB remote protocol.  This is because
>  the SHLIBs are handled using only memory read/writes and breakpoints.
>
>  The ``exercise left to the reader'' is getting what was native-only
>  SHLIB code re-written in a way that is host independant.
>
>  good luck,
>          Andrew

>  Kevin Buettner wrote:
> > Stephen Smith wrote:
> > On the target I have the application testapp.exe and the library
> > libtestlib.so.  When the OS loads testapp.exe and libtestlib.so it
> > does the fixups and (since we wrote the OS and the gdbserver) we can
> > see the elf headers for both files.  We also currently can debug
> > testapp.exe itself.
> >
> > Now, the function main() has a call to lib1Func() which is defined
> > inside of libtestlib.so.  I would like to trace into that function.
> >
> > Questions:
> >      1)  In the protocol
> >            http://sources.redhat.com/gdb/onlinedocs/gdb_14.html#SEC120
> >          I don't see a way to pass back the fixup results that the loader
> >          performed.  Don't I need to do that?
>
> Maybe, maybe not.  As Andrew indicated in his message, you might
> be able to do it all by reading memory, writing memory, and setting
> breakpoints.  In the event that you can't, I suggest using the "q"
> packet so that GDB can fetch the shared library information from
> gdbserver.  You'll need to modify gdb to generate (send) the "q"
> packet at the appropriate point in the code (which will likely be in
> your solib backend) and you'll need to modify gdbserver to recognize
> your special "q" packet and return the shared library information in a
> mutually agreed upon format.
>
> >      2) When I step into the function, lib1Func(), how does the
> >         gdbserver tell gdb that it needs to load the symbol table
> >         from the file libtestlib.so?
>
> The idea is for the symbol table to be loaded (by GDB) prior to ending
> up in lib1Func().  For this to happen, GDB needs to be told when a
> shared library has been loaded by the dynamic linker.  Again, one of
> the ways this is commonly done is for gdb to set an internal
> breakpoint in a special do-nothing function that the shared library
> machinery agrees to call after it's loaded a shared library.  But it
> could be done in other ways too.
>
> Anyway, once GDB has been told that there are (potentially) new
> libraries loaded, GDB then attempts to find the load information
> that you refer to.  It then loads the symbol table and applies
> the necessary relocations.
>
> The point is that all of this occurs before you've ever hit lib1Func().
>
> Kevin