Re: [RFA][branch] Fix DVC calculation for booke ppc

["Ulrich Weigand" <uweigand@de.ibm.com>]

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