From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cagney To: Michael Snyder Cc: Jonathan Larmour , gdb-patches@sources.redhat.com Subject: Re: [RFA]: Remote protocol symbol lookup service. Date: Wed, 06 Jun 2001 03:23:00 -0000 Message-id: <3B1E04D2.6090207@cygnus.com> References: <3AF08427.3522D20E@cygnus.com> <200105031127.f43BRQV08886@localhost.localdomain> <3AF190B2.7C7AB8B8@cygnus.com> <3AF19460.5E59B957@redhat.com> <3AF199A3.886F469E@cygnus.com> X-SW-Source: 2001-06/msg00048.html > 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