From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30932 invoked by alias); 5 Apr 2011 22:51:29 -0000 Received: (qmail 30923 invoked by uid 22791); 5 Apr 2011 22:51:28 -0000 X-SWARE-Spam-Status: No, hits=-1.3 required=5.0 tests=AWL,BAYES_00,MSGID_FROM_MTA_HEADER,SPF_SOFTFAIL,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mtagate6.uk.ibm.com (HELO mtagate6.uk.ibm.com) (194.196.100.166) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 05 Apr 2011 22:51:23 +0000 Received: from d06nrmr1707.portsmouth.uk.ibm.com (d06nrmr1707.portsmouth.uk.ibm.com [9.149.39.225]) by mtagate6.uk.ibm.com (8.13.1/8.13.1) with ESMTP id p35MpKjt028285 for ; Tue, 5 Apr 2011 22:51:20 GMT Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1707.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p35Mq24K1880216 for ; Tue, 5 Apr 2011 23:52:02 +0100 Received: from d06av02.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p35MpKuD015203 for ; Tue, 5 Apr 2011 16:51:20 -0600 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with SMTP id p35MpJbd015182; Tue, 5 Apr 2011 16:51:19 -0600 Message-Id: <201104052251.p35MpJbd015182@d06av02.portsmouth.uk.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Wed, 06 Apr 2011 00:51:19 +0200 Subject: Re: [RFA][branch] Fix DVC calculation for booke ppc To: bauerman@br.ibm.com (Thiago Jung Bauermann) Date: Tue, 05 Apr 2011 22:51:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org (gdb-patches ml) In-Reply-To: <1302031479.2511.90.camel@hactar> from "Thiago Jung Bauermann" at Apr 05, 2011 04:24:39 PM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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: 2011-04/txt/msg00079.txt.bz2 Thiago Jung Bauermann wrote: > On Tue, 2011-04-05 at 18:42 +0200, Ulrich Weigand wrote: > > I may have missed some of the discussion behind the current implementation. > > Could you explain again: > > > > - why you're passing an incorrect length of 1 if the "exact watchpoints" > > flag is on? > > It's not incorrect, really. An exact watchpoint triggers only when the > first byte of its memory region is accessed. Another way of saying it is > that an exact watchpoint watches a 1-byte memory region at the given > address (or at the address of the given variable). Ah, I see. What was confusing me is that if you watch, say, a 4-byte integer variable, even an exact watchpoint will trigger if its low byte changes. But in fact it triggers only if the access happens via a 4-byte store using the exact address of the variable -- and in that case, a write actually occurs to the high byte too, even if it is the same value. Yes, I agree that length 1 is arguably a correct way to represent this semantics, then. > > - why you're only supporting hardware-accelerated conditions if the length > > is 1? > > That is a limitation of BookE processors. You can't make a DVC register > control a ranged watchpoint. Huh, OK. > > Note that while you say that the condition needs to have a strict form, > > you don't currently actually *verify* this: if you have a command of the > > form "watch A if B == C", you only verify that A and B *start* at the > > same address -- you really need to also verify that A and B have the > > same length -- but you cannot because the length of A is not available > > to the target since you're always getting 1 for length. > > How important is it to enforce that? The "watch A if B == C" case could > occur for a union (watch u.i if u.c == 'a'). It could even be useful in > that situation. Is there a drawback in permitting this? I had been under the impression that the correctness of your patch would *rely* on that property being enforced; it seemed to me you were trying to reconstruct the length of the original variable being watched from the length of the variable occuring in the condition. However, that is actually incorrect -- the length of the variable being watched is indeed irrelevant, even when evaluating a condition. What is needed is in fact exactly the length of the variable occuring in the condition, which is what your patch determines. Given that, I withdraw my objection; sorry for the confusion and thanks for your extra explanation. Your patch is OK for mainline. (The branch is for Joel to decide.) Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com