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

Andrew Cagney
2004-03-11T21:27:56Z

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