This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]