From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1774 invoked by alias); 25 Feb 2004 05:47: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 1766 invoked from network); 25 Feb 2004 05:47:28 -0000 Received: from unknown (HELO monty-python.gnu.org) (199.232.76.173) by sources.redhat.com with SMTP; 25 Feb 2004 05:47:28 -0000 Received: from [207.232.27.5] (helo=WST0054) by monty-python.gnu.org with asmtp (Exim 4.30) id 1Avrt1-0003ri-AZ; Wed, 25 Feb 2004 00:47:11 -0500 Date: Wed, 25 Feb 2004 05:47:00 -0000 Message-Id: From: Eli Zaretskii To: Roland McGrath CC: gdb@sources.redhat.com In-reply-to: <200402242321.i1ONLTPE001897@magilla.sf.frob.com> (message from Roland McGrath on Tue, 24 Feb 2004 15:21:29 -0800) Subject: Re: remote protocol support for TARGET_OBJECT_AUXV Reply-to: Eli Zaretskii References: <200402242321.i1ONLTPE001897@magilla.sf.frob.com> X-SW-Source: 2004-02/txt/msg00359.txt.bz2 > 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? > I think the manual may already be inconsistent with itself in the > formatting style for packet text. True. We are trying to fix the inconsistencies as we find them, but there's still a lot of work.