From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kevin Buettner To: Stephen Smith , GDB Subject: Re: GDB and shared libraries Date: Mon, 26 Feb 2001 23:10:00 -0000 Message-id: <1010227070946.ZM13817@ocotillo.lan> 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> X-SW-Source: 2001-02/msg00406.html Stephen, Without knowing more about the shared library mechanism of the proprietary embeddded OS, it is difficult to say. For an SVR4-like shared library system, gdb does not need any help from the target's gdb server beyond that which it already provides (reading memory, writing memory, etc) for normal debugging. The reason for this is that GDB is able to obtain all the information it needs regarding the dynamic linker's activities from the memory of the target process. It is certainly possible that the OS you are dealing with provides the information in a similar, albeit different way. Or (more likely) it's possible that the OS provides some other interface for getting at this information. Again, the two things you need are 1) some way to be notified that the dynamic linker has loaded (or unloaded) one of the shared libraries and 2) some way to get the names of the libraries, their load addresses, and perhaps other assorted information. You'll need to consult the docs for your proprietary OS and figure out what these mechanisms are. It's quite possible that they've provided you with a debugging API for getting at this information. Anyway, once you've figured out these details, you'll still need to put a shared library backend on your target. Fortunately, if you make the target stub (gdb server) do most of the work, it ought to be pretty simple. I think the generally accepted mechanism for gdb to request this kind of target/stub-specific information is the "q" packet. GDB's remote protocol is documented at http://sources.redhat.com/gdb/onlinedocs/gdb_14.html#SEC120 At this point, I'll let others jump in because my experience with the remote protocol is actually rather limited... Kevin On Feb 26, 10:06pm, Stephen Smith wrote: > Subject: Re: GDB and shared libraries > Ah, now I know why we are not communicating. > > I have an embedded system with a proprietary OS. This system has a minimal gdb server running on it. Let's call this > the target > system. > > My host is a Windows NT/Cygwin or Linux Box running gdb which is talking to the gdb server on the target machine. > The problem is that I have a process running on the target (no video, X, etc.) and am debugging on the host. My process > uses a shared library and I need to add the capability of tracing into it. > > Ok, what do I need to add (commands, data, etc.) to my gdb server to trace into these libraries? Is the spec written > down? > > Kevin Buettner wrote: > > > On Feb 26, 6:17pm, Stephen Smith wrote: > > > > > I am told that the "minimal" (and I don't know how minimal) > > > gdbserver doesn't follow the SVR4 spec. Well, I could have fun. > > > > Okay, you've lost me. Where does gdbserver enter into the picture? > > > > Kevin >-- End of excerpt from Stephen Smith