From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30012 invoked by alias); 29 Sep 2009 20:09:25 -0000 Received: (qmail 30002 invoked by uid 22791); 29 Sep 2009 20:09:25 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from e24smtp02.br.ibm.com (HELO e24smtp02.br.ibm.com) (32.104.18.86) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 29 Sep 2009 20:09:18 +0000 Received: from mailhub3.br.ibm.com (mailhub3.br.ibm.com [9.18.232.110]) by e24smtp02.br.ibm.com (8.14.3/8.13.1) with ESMTP id n8TKLN5R020399 for ; Tue, 29 Sep 2009 17:21:23 -0300 Received: from d24av02.br.ibm.com (d24av02.br.ibm.com [9.18.232.47]) by mailhub3.br.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id n8TK9voT1949814 for ; Tue, 29 Sep 2009 17:09:57 -0300 Received: from d24av02.br.ibm.com (loopback [127.0.0.1]) by d24av02.br.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n8TK9EmG022219 for ; Tue, 29 Sep 2009 17:09:14 -0300 Received: from miki.localnet ([9.8.4.16]) by d24av02.br.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n8TK9E9G022216 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Sep 2009 17:09:14 -0300 From: =?iso-8859-1?q?S=E9rgio_Durigan_J=FAnior?= To: Daniel Jacobowitz Subject: Re: Modifications on gdbserver Date: Tue, 29 Sep 2009 20:09:00 -0000 User-Agent: KMail/1.12.1 (Linux/2.6.30.4; KDE/4.3.1; i686; ; ) Cc: gdb@sourceware.org References: <200909291640.14995.sergiodj@linux.vnet.ibm.com> <20090929194756.GA25953@caradoc.them.org> In-Reply-To: <20090929194756.GA25953@caradoc.them.org> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Message-Id: <200909291709.12802.sergiodj@linux.vnet.ibm.com> X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2009-09/txt/msg00325.txt.bz2 Hi Daniel, On Tuesday 29 September 2009, Daniel Jacobowitz wrote: > On Tue, Sep 29, 2009 at 04:40:14PM -0300, S=E9rgio Durigan J=FAnior wrote: > > 1) I could extend the remote protocol and include one more type of `Z' > > packet (`Z5', for example) which would represent this type of hardware > > breakpoint. > > > > 2) I could extend the existing `Z1' (hardware breakpoint) packet in ord= er > > to include a "length" (or "range") parameter. This will be different > > from the existing "size" parameter, because "size" is currently used the > > size of the instruction on the architecture. > > > > What do you think? Considering that there will be more "special" types > > of hardware breakpoints/watchpoints, probably I should choose (2) and t= ry > > to modify the remote protocol as few as possible. Do you agree? Also, > > do you see other option(s) that could be better for this case? >=20 > The vital thing to remember when modifying the remote protocol is to > be compatible. We shouldn't send packets to existing servers that > won't understand them. So I think (1) is better, because then we can > probe for the existance of the new packet and refuse to set > watchpoints if the target can't implement them. If you change an > existing packet, it's impossible to guess all the ways existing > servers will parse it incorrectly :-) You are right, I wasn't thinking about backwards-compatibility. I am proba= bly=20 going to have to add some more packets to the protocol because there are ot= her=20 special types of breakpoints/watchpoints that I would like to add. I will= =20 certainly ask for more opinions if I get stuck. Thank you for answering this, --=20 S=E9rgio Durigan J=FAnior Linux on Power Toolchain - Software Engineer Linux Technology Center - LTC IBM Brazil