This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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



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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]