From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25323 invoked by alias); 29 Sep 2009 19:48:05 -0000 Received: (qmail 25312 invoked by uid 22791); 29 Sep 2009 19:48:04 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 29 Sep 2009 19:47:59 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 9E64010EC2; Tue, 29 Sep 2009 19:48:31 +0000 (GMT) Received: from caradoc.them.org (209.195.188.212.nauticom.net [209.195.188.212]) by nan.false.org (Postfix) with ESMTP id 8809210EB1; Tue, 29 Sep 2009 19:48:31 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1Msig0-0006lA-O0; Tue, 29 Sep 2009 15:47:56 -0400 Date: Tue, 29 Sep 2009 19:48:00 -0000 From: Daniel Jacobowitz To: =?iso-8859-1?Q?S=E9rgio_Durigan_J=FAnior?= Cc: gdb@sourceware.org Subject: Re: Modifications on gdbserver Message-ID: <20090929194756.GA25953@caradoc.them.org> Mail-Followup-To: =?iso-8859-1?Q?S=E9rgio_Durigan_J=FAnior?= , gdb@sourceware.org References: <200909291640.14995.sergiodj@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <200909291640.14995.sergiodj@linux.vnet.ibm.com> User-Agent: Mutt/1.5.20 (2009-06-14) 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/msg00324.txt.bz2 On Tue, Sep 29, 2009 at 04:40:14PM -0300, Sérgio Durigan Júnior 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 order 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 try 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? 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 :-) New packets are a hassle to add, enable, probe, and document, but it's mechanical and safe. -- Daniel Jacobowitz CodeSourcery