Re: [RFC] Extend remote protocol to allow symbol look-up service.

[Michael Snyder <msnyder at cygnus dot com>]

Jim Blandy wrote:
> 
> Michael Snyder <msnyder@cygnus.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.