From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14742 invoked by alias); 11 Mar 2004 21:27:56 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 14733 invoked from network); 11 Mar 2004 21:27:54 -0000 Received: from unknown (HELO localhost.redhat.com) (216.129.200.20) by sources.redhat.com with SMTP; 11 Mar 2004 21:27:54 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 183FC2B92; Thu, 11 Mar 2004 16:27:17 -0500 (EST) Message-ID: <4050D9B4.7080102@gnu.org> Date: Thu, 11 Mar 2004 21:27:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-GB; rv:1.4.1) Gecko/20040217 MIME-Version: 1.0 To: Daniel Jacobowitz Cc: gdb@sources.redhat.com Subject: Re: [remote protocol] Allow qSymbol response to continue packets References: <20040306235253.GA10376@nevyn.them.org> <4050C69E.7060906@gnu.org> <20040311201632.GA26795@nevyn.them.org> In-Reply-To: <20040311201632.GA26795@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-03/txt/msg00108.txt.bz2 >>> 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