This is the mail archive of the gdb-patches@sources.redhat.com 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:breakpoint] Correctly count watchpoints


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


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