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

[Eli Zaretskii <eliz at delorie dot com>]

> Date: Thu, 03 Aug 2000 13:21:47 +1000
> From: Andrew Cagney <ac131313@cygnus.com>
> 
> I.E. delay assigning watchpoints to hardware/software until the last
> moment.  Instead of having watch_command_1()  try to select a hw/sw
> watchpoint before it knows the answer, the code inserting the watchpoint
> could do it and just set ->hw if it succeeded.

Yes, I think this is the only reasonable way, eventually.

The problem is that the code which is run when the user says "watch
foo" doesn't know how many other watchpoints, and of what kind, will
be needed when the inferior is resumed.  In particular, all kinds of
breakpoints with commands that set, reset, or enable watchpoints may
be lying around; a target may be able to combine several watchpoints
into one, but only under some conditions; etc.  You don't know all
that stuff until it's time to resume, and only the target code knows
the entire truth.

Automatic fallback to software watchpoints might be useful, but IMHO
it must be a user option, because in many cases, if I know that my
resources for hardware watchpoints are not enough to cover all of the
watches, I might wish to reconsider instead of letting the program to
crawl...

However, with the current machinery, it is very hard to delay the
hw/sw decision to the point where the inferior is resumed.  This is
because high-level code in GDB needs to know whether there are any
software watchpoints, to arrange for single-stepping.  Since the
decision can only be reliably made by the target-specific code, by the
time it knows that, it's too late.  We need some way of communicating
that information back to GDB's application code, before resume() and
its brethren is called.