From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31437 invoked by alias); 25 Feb 2004 14:34:20 -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 31428 invoked from network); 25 Feb 2004 14:34:18 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 25 Feb 2004 14:34:18 -0000 Received: from drow by nevyn.them.org with local (Exim 4.30 #1 (Debian)) id 1Aw076-0004la-4O; Wed, 25 Feb 2004 09:34:16 -0500 Date: Wed, 25 Feb 2004 14:34:00 -0000 From: Daniel Jacobowitz To: Eli Zaretskii Cc: Roland McGrath , gdb@sources.redhat.com Subject: Re: remote protocol support for TARGET_OBJECT_AUXV Message-ID: <20040225143415.GA18298@nevyn.them.org> Mail-Followup-To: Eli Zaretskii , Roland McGrath , gdb@sources.redhat.com References: <200402242321.i1ONLTPE001897@magilla.sf.frob.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.1i X-SW-Source: 2004-02/txt/msg00361.txt.bz2 On Wed, Feb 25, 2004 at 07:48:42AM +0200, Eli Zaretskii wrote: > > Date: Tue, 24 Feb 2004 15:21:29 -0800 > > From: Roland McGrath > > > > > I suggest using @var{nn} (lower-case) instead of @var{NN}, since that > > > should look better in the printed manual. Also, please explain in > > > the text what does @var{nn} stand for; I assume it's a number that > > > tells what kind of error happened, but I think the manual shouldn't > > > leave that to reader's guesses. > > > > I copied this part of the documentation, and protocol behavior, from the > > other existing protocol requests. As far as I can tell, they are all > > underspecified. What gdbserver seems to do is actually write "ENN" (two > > literal 'N's). So go figure. I'd be happy to change my additions to > > reference a standard explanation of what error packets really look like. > > If gdbserver prints a literal "ENN", then @var is wrong. > > Does anybody know what's the story here, why ENN is printed and what > it should be? Is this perhaps a bug? It predates my work with gdbserver. My guess is that someone saw ENN in the manual, realized that GDB didn't parse the error numbers to do anything useful, and decided not to bother coming up with some. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer