From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13392 invoked by alias); 11 Mar 2004 20:16:33 -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 13384 invoked from network); 11 Mar 2004 20:16:33 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 11 Mar 2004 20:16:33 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1B1WbY-0007AJ-GP; Thu, 11 Mar 2004 15:16:32 -0500 Date: Thu, 11 Mar 2004 20:16:00 -0000 From: Daniel Jacobowitz To: Andrew Cagney Cc: gdb@sources.redhat.com Subject: Re: [remote protocol] Allow qSymbol response to continue packets Message-ID: <20040311201632.GA26795@nevyn.them.org> Mail-Followup-To: Andrew Cagney , gdb@sources.redhat.com References: <20040306235253.GA10376@nevyn.them.org> <4050C69E.7060906@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4050C69E.7060906@gnu.org> User-Agent: Mutt/1.5.1i X-SW-Source: 2004-03/txt/msg00106.txt.bz2 On Thu, Mar 11, 2004 at 03:05:50PM -0500, Andrew Cagney wrote: > >I'd like to propose the attached as an extension to the remote protocol. > >The code implementing this change is here: > > http://sources.redhat.com/ml/gdb-patches/2004-02/msg00000.html > > > >>From my original post: > > As Amit Kale mentioned in December, to support NPTL gdbserver needs to > > look up symbols during remote_wait. The existing qSymbol model assumes > > that only at objfile loads (i.e. during td_ta_new) do we need to look up > > symbols; NPTL looks up symbols lazily when it needs them, which includes > > at the creation of the first child thread. This patch (which, I know, > > needs a matching change for the manual) allows qSymbol: queries as a > > response to remote_wait, in much the same way as the file I/O protocol. > > > >So here's the manual page and a description of the change. Thoughts? > > This isn't sufficient: > > >+@item qSymbol:@var{sym_name} > >+ > >+The target is requesting the address of a symbol. @value{GDBN} replies > >with > >+a @code{qSymbol} packet providing the address of @var{sym_name} if > >available > >+(@pxref{General Query Packets}). > >+ > >+As with @code{F}, this response does not terminate the current resume > >+action. @value{GDBN} continues waiting for another stop packet. > >+ > > 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 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. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer