This is the mail archive of the
mailing list for the GDB project.
Re: [RFC] Extend remote protocol to allow symbol look-up service.
- To: Jim Blandy <jimb at cygnus dot com>
- Subject: Re: [RFC] Extend remote protocol to allow symbol look-up service.
- From: Michael Snyder <msnyder at cygnus dot com>
- Date: Thu, 19 Apr 2001 15:07:12 -0700
- CC: gdb-patches at sources dot redhat dot com, jtc at redback dot com
- Organization: Red Hat
- References: <3ADCD1B8.772C5247@cygnus.com> <firstname.lastname@example.org>
Jim Blandy wrote:
> Michael Snyder <email@example.com> writes:
> > Surprising as it may seem, there are circumstances when a remote
> > target stub may need to know the values of symbols in the debuggee.
> > The case that I'm working from is multi-threaded debugging under
> > Solaris and Linux. Both platforms make use of a debugging support
> > library called libthread-db, which exports a debugging interface
> > into the native thread library. It shields the debugger from
> > knowledge about the thread library internals, but in return it
> > needs to know the addresses of thread library data objects in the
> > child, so that it can go rooting around in them.
> This sounds half-baked.
> libthread-db is something that gets linked into a debugger, not a
> stub. What is libthread-db doing getting linked into a stub?
Because I'd have to add even more new protocol if I put it on
the debugger side. For example, when one thread stops and I need
to stop all the rest. There's no way to express that in the
remote protocol. And even if there was, it would be too slow:
the threads would get all out of sync.
> And if it is on the stub, and there's some sort of dynamic linker
> there on the target, why can't it ask the dynamic linker for the
> symbol values?
Because I'm asking for symbols from the child, which is not
linked into the stub.