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

[Andrew Cagney <cagney@gnu.org>]

>>> look through the File-I/O section that discuss cntrl-c.
>>> 
>>> I think something based on the existing F packet would be better.  At 
>>> least that way we have a situtation where the clear intent is for 
>>> identical semantics.
> 
> 
> 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:

> @node The Ctrl-C message
> @subsection The Ctrl-C message
> @cindex ctrl-c message, in file-i/o protocol
> 
> A special case is, if the @var{Ctrl-C flag} is set in the @value{GDBN}
> reply packet.  In this case the target should behave, as if it had
> gotten a break message.  The meaning for the target is ``system call
> interupted by @code{SIGINT}''.  Consequentially, the target should actually stop
> (as with a break message) and return to @value{GDBN} with a @code{T02}
> packet.  In this case, it's important for the target to know, in which
> state the system call was interrupted.  Since this action is by design
> not an atomic operation, we have to differ between two cases:
> 
> @itemize @bullet
> @item
> The system call hasn't been performed on the host yet.
> 
> @item
> The system call on the host has been finished.
> 
> @end itemize
> 
> These two states can be distinguished by the target by the value of the
> returned @code{errno}.  If it's the protocol representation of @code{EINTR}, the
>  system
> call hasn't been performed.  This is equivalent to the @code{EINTR} handling
> on POSIX systems.  In any other case, the target may presume that the
> system call has been finished --- successful or not --- and should behave
> as if the break message arrived right after the system call.
> 
> @value{GDBN} must behave reliable.  If the system call has not been called
> yet, @value{GDBN} may send the @code{F} reply immediately, setting @code{EINTR} 
> as
> @code{errno} in the packet.  If the system call on the host has been finished
> before the user requests a break, the full action must be finshed by
> @value{GDBN}.  This requires sending @code{M} or @code{X} packets as they fit.
> The @code{F} packet may only be send when either nothing has happened
> or the full action has been completed.

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.

> That keeps the stub implementation much simpler.  And the client
> implementation is easy using blocked signals.

> Implementing something as you describe would be a bit trickier in
> gdbserver; I'd have to force-stop all threads and then fake a SIGINT
> event.

You need to handle such race conditions anyway.

-> c
<- qSymbol | cntrl-c ->

Andrew