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
On Thu, Feb 26, 2004 at 08:15:00AM +0200, Eli Zaretskii wrote:
> > Date: Wed, 25 Feb 2004 11:06:15 -0500
> > From: Daniel Jacobowitz <drow@false.org>
> > >
> > > Er, no. "Enn" as a reply packet is a fundamental part of the protocol
> > > and can't be removed. Whats lacking is the formal specification of its
> > > contents. For the moment I'd leave that part of roland's doco as is.
> >
> > Yeah, I agree. Eli, it does have a useful meaning: it means that an
> > error occured. It just neglects to tell us _what_ :)
>
> Sorry, I must be misunderstanding the issue. So, once again, could
> someone please explain to my confused self what is the meaning of "NN"
> in "ENN"?
Theoretically, it ought to be an error code. i.e. it ought to tell GDB
what has gone wrong.
But GDB doesn't interpret the error code. I just skimmed remote.c; in
some places it checks for starts-with-E; in some it checks for 'E' and
length 3; in some it checks for 'E' and length 3 and digits; in some it
checks for 'E' and length 3 and hex digits. The last is, I think,
correct.
In any case, you're right that it ought to be corrected. I'm not going
to correct it to the full extent of defining error codes, but I will
make it return E01 for all errors instead of ENN; that should fix a bug
I noticed yesterday.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer