From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16285 invoked by alias); 30 Sep 2002 18:26:52 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 16273 invoked from network); 30 Sep 2002 18:26:51 -0000 Received: from unknown (HELO balder.inter.net.il) (192.114.186.15) by sources.redhat.com with SMTP; 30 Sep 2002 18:26:51 -0000 Received: from Zaretsky ([80.230.2.40]) by balder.inter.net.il (Mirapoint Messaging Server MOS 3.1.0.58-GA) with ESMTP id BUH04417; Mon, 30 Sep 2002 21:26:38 +0300 (IDT) Date: Mon, 30 Sep 2002 11:26:00 -0000 From: "Eli Zaretskii" To: ac131313@redhat.com Message-Id: <9743-Mon30Sep2002212639+0200-eliz@is.elta.co.il> CC: gdb-patches@sources.redhat.com In-reply-to: <3D987D2D.6010605@redhat.com> (message from Andrew Cagney on Mon, 30 Sep 2002 12:34:53 -0400) Subject: Re: [rfa:breakpoint] Correctly count watchpoints Reply-to: Eli Zaretskii References: <3D987D2D.6010605@redhat.com> X-SW-Source: 2002-09/txt/msg00766.txt.bz2 > Date: Mon, 30 Sep 2002 12:34:53 -0400 > From: Andrew Cagney > > Each watch > element / location / value in the watchpoint expression is assumed to > consume one watch resource. Given that this assumption doesn't hold on at least one very popular architecture, is it a useful assumption? > Anyway, the problem you refer to is why I was thinking of re-defining > TARGET_REGION_OK_FOR_HW_WATCHPOINT() so that it returns the number of > watchpoint resources required to watch addr/len. If {&a, sizeof a} > required two registers it could return two. But this is very hard or even impossible to do in practice. For example, on a i386, if there are two watchpoint that watch the same 4-byte aligned int variable, you need only one debug register to watch them both, so counting each one as taking one resource is incorrect. But you cannot return the correct result unless you are presented with the entire list of watchpoints GDB would like to set. Alas, GDB's application code examines the watchpoints one by one and queries the target vector about each one of them in order. Thus, the target vector doesn't see the whole picture and therefore cannot give the right answer. What is the value of the result you get if we _know_ in advance that it will be incorrect, sometimes grossly incorrect, in some not very rare cases? > I think it would be helpful if, at least in maintainer mode, the user > could see how many resources have been allocated to a watchpoint. If this is for maintainers, the count should be accurate. The i386 native debugging implements a maintainer-mode command to do that, but it manipulates target-side data, and only works after all watchpoints have been inserted. > (I've a sinking feeling that hardware breakpoints have the same problem > ...). Indeed they do.