This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]