Re: [patch 2/3] Implement support for PowerPC BookE ranged watchpoints

[Thiago Jung Bauermann <bauerman@br.ibm.com>]

On Tue, 2010-11-23 at 23:16 +0000, Pedro Alves wrote:
> On Tuesday 23 November 2010 21:51:40, Thiago Jung Bauermann wrote:
> > Ok?
> 
> Apologies for jumping in so late, but, I don't think I understand
> why does the user need to know that a watchpoint is "ranged"
> or not.  All (low-level) watchpoints are ranged,

Good point. At the time these patches were made, GDB didn't behave that
way, but it was fixed one year ago already[1]. I guess I just kept the
old mentality...

> and what's
> relevant here is only the width of the range the hardware can watch,
> but that is already a parameter to the target_insert_watchpoint
> method.  So I guess my question is, why can't the target backend
> manage whether to use a range or "normal" watchpoint when asked to
> inserted a watchpoint?  Is it the watch resource accounting done
> by breakpoint.c (which is known to be something that should just
> go away)?

Yes, the resource accounting is an issue. But also, the target needs to
know that it's being asked to watch a region which is expected to have
accesses in the middle of it. This is because of the difference of how
hardware watchpoints work in server and embedded PowerPC processors. In
the former, a hardware watchpoint triggers when any byte within an 8
byte window starting at the given address is accessed. In the latter,
only accesses at the given address trigger the watchpoint.

So for an embedded powerpc processor, it's not enough to know that it
should watch a 4 byte region at a given address. If it represents an
integer and thus it can expect accesses only at that address then a
regular watchpoint is enough. But if it's an array of four chars, then
it needs two watchpoint registers to set up a hardware watchpoint...

So that's way I created a target_insert_ranged_watchpoint. The other
option would be to add a flag to target_insert_watchpoint...
-- 
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center


[1] - http://sourceware.org/ml/gdb-patches/2009-12/msg00368.html