From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17333 invoked by alias); 5 Apr 2011 19:24:56 -0000 Received: (qmail 17322 invoked by uid 22791); 5 Apr 2011 19:24:54 -0000 X-SWARE-Spam-Status: No, hits=-1.5 required=5.0 tests=AWL,BAYES_00,SPF_SOFTFAIL,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from e8.ny.us.ibm.com (HELO e8.ny.us.ibm.com) (32.97.182.138) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 05 Apr 2011 19:24:48 +0000 Received: from d01dlp02.pok.ibm.com (d01dlp02.pok.ibm.com [9.56.224.85]) by e8.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p35IxjnE023120 for ; Tue, 5 Apr 2011 14:59:45 -0400 Received: from d01relay05.pok.ibm.com (d01relay05.pok.ibm.com [9.56.227.237]) by d01dlp02.pok.ibm.com (Postfix) with ESMTP id 0BCF96E803C for ; Tue, 5 Apr 2011 15:24:47 -0400 (EDT) Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p35JOklB225140 for ; Tue, 5 Apr 2011 15:24:46 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p35JOkE2019220 for ; Tue, 5 Apr 2011 16:24:46 -0300 Received: from [9.12.226.193] ([9.12.226.193]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p35JOiTx019197; Tue, 5 Apr 2011 16:24:44 -0300 Subject: Re: [RFA][branch] Fix DVC calculation for booke ppc From: Thiago Jung Bauermann To: Ulrich Weigand Cc: gdb-patches ml In-Reply-To: <201104051642.p35Gg0Op012678@d06av02.portsmouth.uk.ibm.com> References: <201104051642.p35Gg0Op012678@d06av02.portsmouth.uk.ibm.com> Content-Type: text/plain; charset="UTF-8" Date: Tue, 05 Apr 2011 19:24:00 -0000 Message-ID: <1302031479.2511.90.camel@hactar> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Content-Scanned: Fidelis XPS MAILER X-IsSubscribed: yes 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/msg00077.txt.bz2 On Tue, 2011-04-05 at 18:42 +0200, Ulrich Weigand wrote: > Thiago Jung Bauermann wrotE: > > The bug was introduced by a patch of mine (doh). > > ppc-linux-nat.c:calculate_dvc uses the watchpoint length that is passed > > to target_insert_watchpoint to calculate the contents of the Data Value > > Compare register. The problem is that for the ranged watchpoints feature > > I changed GDB to pass 1 as length if the "set powerpc exact-watchpoints" > > flag is on. This messes up things for calculate_dvc. > > > > This patch makes check_condition obtain the length of the watchpoint > > region from the condition expression, so that it can be passed to > > calculate_dvc. This works because for a condition to be eligible for > > hardware acceleration, it needs to have a strict form: > > > > (gdb) watch ADDRESS|VARIABLE \ > > if ADDRESS|VARIABLE == CONSTANT EXPRESSION > > > > which means that the ADDRESS|VARIABLE part is the same as the watchpoint > > region. > > Huh. That strikes me as a hack to work around another hack :-/ That's one way of looking at it, yes. :-) > 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). > - 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. > 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? > It seems to me the "right way" would be for the common parts to always > pass correct information (address, length, condition, ...) to the target, > and then for the target to look at the request and choose the best > possible hardware means to implement this particular request ... I agree it's the right way, but is the gain worth the wide-reaching change? -- []'s Thiago Jung Bauermann IBM Linux Technology Center