This is the mail archive of the
mailing list for the GDB project.
Re: GDB and shared libraries
- To: Stephen Smith <ischis2 at home dot com>, GDB <gdb at sourceware dot cygnus dot com>
- Subject: Re: GDB and shared libraries
- From: Kevin Buettner <kevinb at cygnus dot com>
- Date: Tue, 27 Feb 2001 00:09:47 -0700
- 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>
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
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
At this point, I'll let others jump in because my experience with the
remote protocol is actually rather limited...
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
> 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
> 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