From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10024 invoked by alias); 11 Mar 2004 20:06:29 -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 10015 invoked from network); 11 Mar 2004 20:06:28 -0000 Received: from unknown (HELO localhost.redhat.com) (216.129.200.20) by sources.redhat.com with SMTP; 11 Mar 2004 20:06:28 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 005B12B92; Thu, 11 Mar 2004 15:05:50 -0500 (EST) Message-ID: <4050C69E.7060906@gnu.org> Date: Thu, 11 Mar 2004 20:06: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> In-Reply-To: <20040306235253.GA10376@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-03/txt/msg00105.txt.bz2 > 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. Andrew