This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: [RFA]: Remote protocol symbol lookup service.


Jonathan Larmour wrote:
> 
> Michael Snyder wrote:
> >
> > Jonathan Larmour wrote:
> > >
> > > In article <3AF090AE.4D31F3A@cygnus.com> you write:
> > > >-=-=-=-=-=-
> > > >
> > > >Michael Snyder wrote:
> > > >>
> > > >> Andrew,
> > > >>
> > > >> I've changed the initial message from "Q" to "q" as you suggested, and
> > > >> I've hexified the filenames and symbol names, so that they are not
> > > >> vulnerable to embedded special characters.  If you have a name for the
> > > >> initial message that you would prefer over "qSharedObject", I'm open
> > > >> to suggestions.
> > >
> > > I still think a target should be able to request this at any point
> > > in the remote protocol, and not just when told of a shared object.
> >
> > Yeah?  Would you be willing to implement that?  ;-)
> 
> Isn't it just a case of pretty much cut-and-pasting the bit that acts on a
> symbol request from the target into remote_wait()?

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]