From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13437 invoked by alias); 18 Feb 2003 02:39:15 -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 13408 invoked from network); 18 Feb 2003 02:39:14 -0000 Received: from unknown (HELO localhost.redhat.com) (172.16.49.200) by 172.16.49.205 with SMTP; 18 Feb 2003 02:39:14 -0000 Received: by localhost.redhat.com (Postfix, from userid 1008) id EE11C3CF2; Mon, 17 Feb 2003 21:04:08 -0500 (EST) Subject: Re: Is stub support for the 's' packet optional or required? In-Reply-To: <1030217235014.ZM670@localhost.localdomain> "from Kevin Buettner at Feb 17, 2003 04:50:15 pm" To: Kevin Buettner Date: Tue, 18 Feb 2003 02:39:00 -0000 Cc: gdb@sources.redhat.com MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII Message-Id: <20030218020408.EE11C3CF2@localhost.redhat.com> From: ac131313@redhat.com (Andrew Cagney) X-SW-Source: 2003-02/txt/msg00292.txt.bz2 > I've been told off-list that it is not required for a stub to > implement support for the 's' packet. I was also told that the > documenation is wrong in this regard. Specifically, it says: > > A stub is required to support the `g', `G', `m', `M', `c', and `s' > commands. All other commands are optional. > > See > http://sources.redhat.com/gdb/current/onlinedocs/gdb_32.html#SEC632 > and > http://world.std.com/~qqi/download/protocol.txt > > (I often find the latter document to be the more useful of the two.) > > I'd like to get other opinions regarding this matter. Also, if it > really is the case that stubs are NOT required to implement support > for the 's' packet, then will all such stubs return the empty response > which indicates that there is no support for that particular packet? If GDB implements software single step, then the `s' packet is never used. Consequently, requiring the unconditional implementation of "s" makes little sense. Note though that, while a target that doesn't support the "s" packet should return "" instead of "T...". remote.c isn't exactly set up to handle this - by the time it realizes it's got a problem it is a bit late. The step-out-of-range code tried to address this but in the process created querky resume semantics. Andrew