Re: [remote protocol] Allow qSymbol response to continue packets

[Andrew Cagney <cagney at gnu dot org>]

> > > > >Could you explain why you this is necessary?
> >
> > >
> >
> > > > >I'm guessing in the File I/O case this handles the user hitting C-c
> > > > >while the client is processing a request, and there is considerable
> > > > >complexity involved in reporting whether the I/O has completed.  But
> > > > >using errno doesn't make any sense in the symbol lookup context and it
> > > > >seems to me easier to make GDB delay sending the C-c to the target
> > > > >until the qSymbol has been processed:
> > > > >  -> c
> > > > >  <- qSymbol:AAAAAAAAAAAAA
> > > > >  Control-C
> > > > >  -> qSymbol:AAAAAAAAAAAAA:012131312
> > > > >  -> \003
> >
> > > Here's the problem:
>
>
> I did read the manual when you referenced it, you don't need to paste
> the whole thing :)

I quoted the relevant section of the manual as it hopefully explained 
why it was necessary.  If that doesn't answer the question then we've a 
bug in the manual.

> > > A user trying to cntrl-c GDB while GDB is taking its time looking up a 
> > > symbol isn't theory.  There needs to be an error/abort mechanism and 
> > > adopting "F" provides that.
> > >
> > > The alternative is to specify some sort of customized q packet semantics 
> > > - giving two callbacks and two different behaviors  - I'm really not 
> > > interested in going there.
>
>
> Perhaps you've noticed that we have hashed minimal symbol table
> lookups?  There is no excuse for symbol table lookups to take long
> enough for there to need to be an abort mechanism.  This is in contrast
> to file I/O which can block.

Protocol's can't make such assumptions.

> I don't think we need to use the heavy-weight mechanism which supports
> interruption for operations that don't need to be interrupted, and I
> can't see a reason to support interruption of this lookup.  If you do,
> please enlighten me.

I think we'll have to disagree on our definitions of heavy weight (if F 
it is too heavy weight then perhaphs we need to remove a few things from 
it).

The protocol needs to specify the failure states, the F packet provides 
that for free.  As I said, I'm really not interested in cooking up 
another callback packet with a different set of failure states.  One is 
enough.

> > > You need to handle such race conditions anyway.
> > >
> > > -> c
> > > <- qSymbol | cntrl-c ->
>
>
> That's a different problem, and it is already correctly handled by
> gdbserver.  We'll write out the qSymbol, read in the Ctrl-C, signal the
> inferior, look again for an ACK, eventually get the ACK.  Then we'd
> wait for and get a qSymbol reply, resume the suspended thread that made
> the lookup request, wait for it, and see the SIGINT we created.

If you've code to handle that you've code to handle a packet containing:

- <retry><cntrl-C>
- <symbol><cntrl-C>

Andrew