From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stephen Smith To: Andrew Cagney , kevinb@cygnus.com Cc: GDB Subject: Re: GDB and shared libraries Date: Wed, 21 Mar 2001 15:59:00 -0000 Message-id: <3AB257E6.56F8C19F@home.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> X-SW-Source: 2001-03/msg00150.html 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