This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFA]: Remote protocol symbol lookup service.
- To: Michael Snyder <msnyder at cygnus dot com>
- Subject: Re: [RFA]: Remote protocol symbol lookup service.
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Wed, 06 Jun 2001 06:24:18 -0400
- Cc: Jonathan Larmour <jlarmour at redhat dot com>,gdb-patches at sources dot redhat dot com
- References: <3AF08427.3522D20E@cygnus.com> <200105031127.f43BRQV08886@localhost.localdomain> <3AF190B2.7C7AB8B8@cygnus.com> <3AF19460.5E59B957@redhat.com> <3AF199A3.886F469E@cygnus.com>
> Hmmm... I suppose so, under the right set of assumptions.
> Such as that the target is not really stopped, and we do not
> need to restart it (as with the 'O' packet).
>
> Andrew? J.T.? Anybody else have an opinion about letting GDB
> respond to new requests while in remote_wait? Basically it's a
> switch statement, so it doesn't really have much impact on
> performance or anything... and of course I could abstract the
> code that responds to the symbol requests into a function.
>
> Or, we could just wait and do this if there's ever a need to.
> For my application (the thread_db interface), this would not
> be useful.
See previous discussion about getting input working across the protocol.
The suggestion was:
o target stop with bogus signal 0
o gdb chat to target: qSymbol? qInput?
o gdb resume target
part of the chat could include a check qSymbol check. A variation might
have the target return a symbol request instead of a stop status.
Andrew