Re: remote protocol support for TARGET_OBJECT_AUXV

[Daniel Jacobowitz <drow@false.org>]

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