This is the mail archive of the
mailing list for the GDB project.
Re: GDB and shared libraries
- To: Andrew Cagney <ac131313 at cygnus dot com>, kevinb at cygnus dot com
- Subject: Re: GDB and shared libraries
- From: Stephen Smith <ischis2 at home dot com>
- Date: Fri, 16 Mar 2001 11:13:58 -0700
- CC: GDB <gdb at sourceware dot cygnus dot com>
- References: <3A84136A.23BAF90F@home.com> <1010209182220.ZM4621@localhost.localdomain> <3A845A56.5EF8F61@home.com> <3A9AB471.5F46554@home.com> <1010226205415.ZM30678@localhost.localdomain> <3A9ADDF4.FD998D6E@home.com> <1010226233506.ZM13209@ocotillo.lan> <3A9B0022.16ABBBE0@home.com> <1010227013252.ZM13444@ocotillo.lan> <3A9B35E4.33B1868B@home.com> <3A9BD1C8.B1C6DDB1@cygnus.com>
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
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
Thanks for helping the newbie.
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,
> 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().