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

[Fernando Nasser <fnasser at cygnus dot com>]

Thanks, that is a very good summary.

Let me comment...


Eli Zaretskii wrote:
> 
> > 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.
> 

Delaying the decision for watchpoints is hard because the software implementation
is something not atomic, much different from the sw breakpoint which is basically
alter a memory position.  The software implementation of watchpoints includes
an arbitrary number of single-steps and processing on inferior event.

Note that once the user realizes his/her target do have hardware support for 
watchpoints he/she can either:
1) Use target first, before inserting watchpoints
2) Add "set harware-watchpoints enable" to her/his .gdbinit file

Nothing that the manual or a good error message text can't fix.


> 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.
> 

The code in breakpoints does collect the necessary information and pass it
as arguments to the macro.  We just have to write the appropriate code for
each architecture.  The check is part architecture dependent and part target
dependent.  My implementation allow for both checks.

The macro (is it already at gdbarch?  If not it should) invokes the architecture
dependent code (in i386-tdep.c in my case) and that uses the target vector above
to check the target dependent parts.

I believe we always should go through these two layers, in that order, for things
that are both arch and target dependent.


> 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...
> 

set hardware-watchpoints disable   (the default will be auto)

> 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.

Exactly.  Unless we want the watchpoint support to remain in the TODO list
for a very long time we must set for a initial solution that does not require
a huge amount of code rewriting.  In this case I would bet it would need a
major architectural change.




-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@cygnus.com
2323 Yonge Street, Suite #300           Tel:  416-482-2661 ext. 311
Toronto, Ontario   M4P 2C9              Fax:  416-482-6299