This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFC] Extend remote protocol to allow symbol look-up service.
- To: Michael Snyder <msnyder at cygnus dot com>
- Subject: Re: [RFC] Extend remote protocol to allow symbol look-up service.
- From: Jim Blandy <jimb at zwingli dot cygnus dot com>
- Date: 19 Apr 2001 15:41:46 -0500
- Cc: gdb-patches at sources dot redhat dot com, jtc at redback dot com
- References: <3ADCD1B8.772C5247@cygnus.com>
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?
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?