This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: remote protocol support for TARGET_OBJECT_AUXV
- From: Daniel Jacobowitz <drow at false dot org>
- To: Eli Zaretskii <eliz at elta dot co dot il>
- Cc: Roland McGrath <roland at redhat dot com>, gdb at sources dot redhat dot com
- Date: Wed, 25 Feb 2004 09:34:16 -0500
- Subject: Re: remote protocol support for TARGET_OBJECT_AUXV
- References: <200402242321.i1ONLTPE001897@magilla.sf.frob.com> <u4qtfg152.fsf@elta.co.il>
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 <roland@redhat.com>
> >
> > > 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