From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26570 invoked by alias); 12 Jan 2010 11:00:03 -0000 Received: (qmail 26547 invoked by uid 22791); 12 Jan 2010 11:00:02 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 12 Jan 2010 10:59:59 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id E0F8541658; Tue, 12 Jan 2010 05:59:57 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Dgbp4JBDUZcA; Tue, 12 Jan 2010 05:59:57 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 63EE24164F; Tue, 12 Jan 2010 05:59:57 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id F198DF595E; Tue, 12 Jan 2010 14:59:42 +0400 (RET) Date: Tue, 12 Jan 2010 11:00:00 -0000 From: Joel Brobecker To: Thiago Jung Bauermann Cc: gdb-patches@sourceware.org, Luis Machado , Matt Tyrlik Subject: Re: [PATCH 3/4] Support ranged and masked watchpoints Message-ID: <20100112105942.GL2007@adacore.com> References: <200912232231.06331.bauerman@br.ibm.com> <200912311520.36690.bauerman@br.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200912311520.36690.bauerman@br.ibm.com> User-Agent: Mutt/1.5.20 (2009-06-14) 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: 2010-01/txt/msg00298.txt.bz2 > > Adds support for the following types of watchpoints: [range watchpoints] In this instance as well, I would like to see if we could push all the logic to the target, by providing all the information the target needs in order to make that decision. One nice upside is that this will allow the target to use both range watchpoint and condition hardware acceleration if the target allows it. Or if it doesn't, not separating the two types of features with separate target watchpoint_insert/remove routines allows the target to choose which one makes most sense if a choice needs to be made. What do you think? -- Joel