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]

Re: Runtiming hw watchpoints; Was: Split up Z packet enable/disable cmd


> Date: Fri, 04 Aug 2000 15:12:16 -0400
> From: Fernando Nasser <fnasser@cygnus.com>
> 
> Eli Zaretskii wrote:
> > 
> > t could do this if it gets the info about all
> > the watchpoints and hardware breakpoints defined previously.
> > Currently, it only gets information about one single watchpoint at a
> > time, and that is not enough, at least on x86.
> > 
> You are absolutely right.  I missed that.  We can add a field in the breakpoint
> structure and store the number of hw registers used by a hw watchpoint.
> Then we can fix hw_watchpoint_used_count() to add them up.
> Does it sound right?

This would be a huge step in the right direction, but it is still not
enough.

Imagine a situation where a user sets 2 different watchpoints at the
same address.  (This might make sense if these watchpoints have
different conditions, for example.)  DJGPP currently can insert such
watchpoints using a single debug register, by implementing reference
counts for debug registers.  I believe that eventually, other x86
platforms will use a similar technique, since the number of debug
registers is so small.  (We had a discussion some time ago where
everybody agreed that all x86 targets should share the code which
handles watchpoints.)

In situations like this, it is not enough to know how many debug
registers are already taken up.  You need to know everything about
those other watchpoints.  (In the x86 case, you need to know only the
type of the watchpoint, and the address and the size of the watched
region, but other platforms might want to know more.)

So I think we have two alternatives to solving this:

  - Make can_use_hardware_watchpoint loop over all the watchpoints
    before you ask it about the additional one, so that the target end
    could get the entire picture.

  - Invent a new API call whereby the target will add and remove the
    info about the watchpoints and breakpoints to some internal
    storage at the target end.

The latter seems like a cleaner solution, and also has a benefit that
it might remove the need for inserting the breakpoints and watchpoints
one by one when resuming: you could simply tell the target to insert
all active ones in one go.  But it does mean more extensive changes...

> But I guess this will only happen if we try to use it for good.
> No pain, no gain :-)

Sure.  Personally, I use watchpoints a lot, and would be glad to see
any improvements in their handling.  The current code in go32-nat.c
works well enough for me, but it is messy and full of pitfalls.  I
will welcome any changes in higher-level APIs that would make this
simpler and cleaner.

> I am merging my Pentium III changes to the current sourceware code.
> I will retest things and post some patches as soon as I get them to
> work again.  We can start from that.

Great!

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