Re: [patch] Fix PR 13392 : check offset of JMP insn

[Stan Shebs <stanshebs@earthlink.net>]

On 3/6/12 12:14 PM, Philippe Waroquiers wrote:
> On Tue, 2012-03-06 at 17:03 +0000, Pedro Alves wrote:
>> We should send an error back to GDB with "E." instead of printing something
>> to gdbserver's console, and leaving the user with a generic and
>> unhelful error.  "4-byte" isn't strictly correct, as this is a signed
>> offset, and I think we can be a bit more clear.  So we end up with:
>>
>>        sprintf (err,
>> 	       "E.Jump back from jump pad too far from tracepoint "
>> 	       "(offset 0x%" PRIx64 ">  int32).", loffset);
>>
>
> In the gdb protocol documentation, all error replies but one
> are described as E NN. Some of them specifies that NN are
> hex digits.
> The exception is the packet qTMinFTPILen:
> the error reply is described as only an E
> (this last sentence intentionnally not finished with a . :).
>
> 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 
theory is that ENN dates nearly to the 4-bit era :-) and is pretty much 
useless without an agreed-upon table of what the different NN values 
mean.  But since there are multiple generations of stubs out there that 
might or might not have assigned their own meanings to NN, those are 
pretty much off-limits now, and so E.<string> is a convenient way to 
extend error returns without disrupting backward compatibility too 
much.  The string is uninterpreted, GDB should just report that an error 
happened and print the string verbatim.

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. :-)

Stan