This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [rfa:breakpoint] Correctly count watchpoints
- From: Eli Zaretskii <eliz at is dot elta dot co dot il>
- To: Andrew Cagney <ac131313 at redhat dot com>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Tue, 1 Oct 2002 06:51:25 +0200 (IST)
- Subject: 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.
> > 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.
> 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.
> 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.