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

[Andrew Cagney <cagney@gnu.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