Documenting E. packet. (was Re: [patch] Fix PR 13392 : check offset of JMP insn)

[Philippe Waroquiers <philippe dot waroquiers at skynet dot be>]

On Tue, 2012-03-06 at 13:47 -0800, Stan Shebs wrote:

> > Is there somewhere a description of what an E. packet is,
> > and when this is allowed ?
> >
...
> It doesn't look like it's officially described in the manual.  The 
...
> 
> It's conceivable that one could do something with GDB that interprets 
> the error reply (whether NN or a string) and does something differently, 
> but in practice, if the target side is reporting errors, things are 
> going straight downhill and the user needs to decide what to do about 
> it.  Also, if a particular result is common enough that GDB has code to 
> cope with it, then maybe it's just another element of the protocol, not 
> really an error. :-)

Effectively, having GDB trying to do something sophisticated depending
on the E NN nr or E. string received from the stub looks difficult.

There is however already some kind of logic in GDB.
E.g. in remote.c, the function trace_error handles differently E.,
E1? and E2?.

There are other places where only E NN is considered as an error.
E. is not considered as an error.
Example: qRcmd.


When I did the Valgrind gdbserver, I had to return a readable error
msg to the user but did not find a way to do that in the doc.
I found the E. by reading the gdb sources and used it (believing
I was doing a nasty thing. But now, I see it is just an officially
accepted error packet, just not documented :).
=> it looks better to document this E. packet.

However, it is not clear to me what is exactly expected for
this documentation/behaviour.

It looks better if at all places where an E NN is accepted by GDB,
GDB would also accept an E. packet.

But that is not the current behaviour, so either remote.c is
changed to consistently accept E NN and E. everywhere,
or the protocol doc must match the current behaviour,
and indicate for each packet if an E NN and/or an E. error is
accepted.

Philippe