From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Snyder To: Jim Blandy Cc: gdb-patches@sources.redhat.com, jtc@redback.com Subject: Re: [RFC] Extend remote protocol to allow symbol look-up service. Date: Thu, 19 Apr 2001 15:07:00 -0000 Message-id: <3ADF6190.5238E691@cygnus.com> References: <3ADCD1B8.772C5247@cygnus.com> X-SW-Source: 2001-04/msg00197.html Jim Blandy wrote: > > Michael Snyder 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.