From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15913 invoked by alias); 7 Mar 2012 21:21:04 -0000 Received: (qmail 15905 invoked by uid 22791); 7 Mar 2012 21:21:03 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE X-Spam-Check-By: sourceware.org Received: from mailrelay009.isp.belgacom.be (HELO mailrelay009.isp.belgacom.be) (195.238.6.176) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 07 Mar 2012 21:20:44 +0000 X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBALDQV09R9oZK/2dsb2JhbAAMOIU0swMBAQEDASNWEAsOCgICJgICVwaIFqdDkiSBL44qgRYEpViCZA Received: from 74.134-246-81.adsl-dyn.isp.belgacom.be (HELO [192.168.1.3]) ([81.246.134.74]) by relay.skynet.be with ESMTP; 07 Mar 2012 22:20:42 +0100 Subject: Re: Documenting E. packet. (was Re: [patch] Fix PR 13392 : check offset of JMP insn) From: Philippe Waroquiers To: Pedro Alves Cc: Stan Shebs , gdb-patches@sourceware.org In-Reply-To: <4F57CC1B.3030104@redhat.com> References: <4F561363.4070702@codesourcery.com> <4F56434F.4030107@redhat.com> <1331064879.2209.11.camel@soleil> <4F568602.8040005@earthlink.net> <1331152865.2209.46.camel@soleil> <4F57CC1B.3030104@redhat.com> Content-Type: text/plain; charset="UTF-8" Date: Wed, 07 Mar 2012 21:21:00 -0000 Message-ID: <1331155249.2209.65.camel@soleil> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit 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/msg00251.txt.bz2 On Wed, 2012-03-07 at 20:59 +0000, Pedro Alves wrote: > > It looks better if at all places where an E NN is accepted by GDB, > > GDB would also accept an E. packet. > > > Yeah, though we'd a careful audit. We should be careful in avoiding the > case of with newer stubs sending "E.xxx" to GDBs that haven't been updated, > and those GDBs not understanding it as an error packet. Not clear to me how this can be achieved. E.g. if qRcmd now accepts an E. error packet in gdb 7.5, and a stub is modified to send such an E., trying to use this stub with gdb 7.4 or before will not give the expected behaviour when E. is returned by the new stub to the old gdb. Unless the new stub would have a way to know that the gdb does not understand E. reply to qRcmd ? > > > 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. > > > In any case, the documentation should be updated. Yes, either both code and doc, or only doc. Philippe