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

Andrew Cagney
2004-03-11T23:21:00Z

>>>> >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