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 Sun, 29 Sep 2002, Andrew Cagney wrote:


(per earlier post) An expression like:

	a + b

requires two watchpoint resources (&a and &b).

What do you mean by ``watchpoint resources''? On a i386, watching &a might require much more than a single debug register, depending on a's size and alignment.
At this point I'm trying desperatly to not define it :-) Each watch element / location / value in the watchpoint expression is assumed to consume one watch resource.

Anyway, the problem you refer to is why I was thinking of re-defining TARGET_REGION_OK_FOR_HW_WATCHPOINT() so that it returns the number of watchpoint resources required to watch addr/len. If {&a, sizeof a} required two registers it could return two.

Such a model is obviously simple and will be sub-optimal in many situtations. I think its sufficient though.

A more complete model would involve extending/generalizing what Marko Mlinar has implemented for the opencore:
http://sources.redhat.com/ml/gdb/2002-09/msg00308.html

When first creating the watchpoint, gdb correctly counts this as two. However, when GDB goes back to compute the number of watchpoints already used, it does a re-count and treats the above (and any watchpoint expression) as only one.

The attached, I belive, fixes this by saving the mem_cnt that was computed.

I agree that the count should at least be consistent.


One thing I wonder about though, should ``info breakpoints'' or ``maint info breakpoints'' display this info?

Only if it's useful. Could you please make a concrete suggestion as to what should be printed about this information?
I think it would be helpful if, at least in maintainer mode, the user could see how many resources have been allocated to a watchpoint. That way (as well as letting me check its working :-) the user would be in a better position to figure out where, exactly, all their watchpoints have gone.

Ok?

Fine with me.
(I've a sinking feeling that hardware breakpoints have the same problem ...).

Andrew



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