Re: [rfa:breakpoint] Correctly count watchpoints

[Andrew Cagney <ac131313@redhat.com>]

> On Mon, 30 Sep 2002, Andrew Cagney wrote:
> 
> 
>> On the i386, one watch resource is two registers.
> 
> 
> Why two?  Some expressions might need 3 registers.  If you use this 
> worst-case scenario, GDB will think it cannot watch more than a single 
> expression, and that some data types, such as double's, and complex 
> aggregates, such as struct's, cannot be watched at all.  It's hardly a 
> Good Thing to refuse to set watchpoints based on inaccurate decisions 
> like this.

You mentioned two :-)

Under the current arangement, an architecture has two choices:

- have target_can_use_hardware_watchpoints() always return true (most 
targets appear to do this) and then error while trying to insert the 
watchpoints.  This is what the i386 currently does.

- have target_can_use...() make use of the counts and return an 
indication based on that

>> > But this is very hard or even impossible to do in practice.  For
>> > example, on a i386, if there are two watchpoint that watch the same
>> > 4-byte aligned int variable, you need only one debug register to watch
>> > them both, so counting each one as taking one resource is incorrect.
> 
>> 
>> That is a bug.  A further change would be to accumulate all the regions 
>> and eliminate any overlap from the count.
> 
> 
> This requires a significant change in the high-level code of GDB: it 
> needs to pass all the information about all the ``active'' watchpoints to 
> the function that tells how many watchpoint resources are required for 
> the next watchpoint.

I'm not so sure.  I think this can be handled by:

- keeping a list of the addr:len pairs needed by each watchpoint (and 
their ``cost'' (hmm, that's the correct word)).

- iterating over all watchpoints, all addr:len pairs eliminating overlap

and this is local to breakpoint.c.

>> For an architecture to try and optimally allocate watchpoint resources, 
>> I don't think (cf opencore code) a list of ADDR:LEN pairs is sufficient. 
>>   Instead it should be provided with all the watchpoint expressions.
> 
> 
> So that means an architecture should know about GDB's expression-parsing 
> code.  In effect, we are going to have the arch-specific code be tightly 
> coupled with arch-independent code in breakpoint.c and friends.

The expression tree, yes.

More scary again, it's on par with a compiler where the code needs to 
assign instructions and registers to expression elements.  As I 
mentioned elsewhere I've seen it come as a feature request twice now.

>> For instance, the hw_resources_used_count() function in my other patch 
>> could be made part of the architecture vector so that architectures, 
>> such as the i386, could override the default model using some other type 
>> of allocation scheme.
> 
> 
> As I write above, overriding the default model is not enough, since the 
> application-level code doesn't feed the architecture with enough info.

Yes.

The function hw_resources_used_count() (nee hw_breakpoint_used_count()) 
is the real core to determining the number of watchpoints that are 
needed.  It has complete information.  I was thinking of allowing 
architectures to plug in a per-architecture equivalent.

Andrew