[patch] Fix PR 13392 : check offset of JMP insn
Stan Shebs
stanshebs@earthlink.net
Tue Mar 6 21:48:00 GMT 2012
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
More information about the Gdb-patches
mailing list