From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15100 invoked by alias); 6 Mar 2012 21:48:12 -0000 Received: (qmail 15085 invoked by uid 22791); 6 Mar 2012 21:48:11 -0000 X-SWARE-Spam-Status: No, hits=-0.6 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,RCVD_IN_DNSWL_NONE,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from elasmtp-curtail.atl.sa.earthlink.net (HELO elasmtp-curtail.atl.sa.earthlink.net) (209.86.89.64) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 06 Mar 2012 21:47:58 +0000 Received: from [68.96.200.16] (helo=macbook2.local) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1S52Ef-0003Yz-Lu for gdb-patches@sourceware.org; Tue, 06 Mar 2012 16:47:57 -0500 Message-ID: <4F568602.8040005@earthlink.net> Date: Tue, 06 Mar 2012 21:48:00 -0000 From: Stan Shebs User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: gdb-patches@sourceware.org Subject: Re: [patch] Fix PR 13392 : check offset of JMP insn References: <4F561363.4070702@codesourcery.com> <4F56434F.4030107@redhat.com> <1331064879.2209.11.camel@soleil> In-Reply-To: <1331064879.2209.11.camel@soleil> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: ae6f8838ff913eba0cc1426638a40ef67e972de0d01da940edc8ed885df6d6b6ecb0d77fe67b345a350badd9bab72f9c350badd9bab72f9c350badd9bab72f9c X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2012-03/txt/msg00209.txt.bz2 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. 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