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: Thu, 03 Aug 2000 15:24:22 +0000
> From: Fernando Nasser <fnasser@cygnus.com>
> 
> > 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.

Perhaps we are talking about slightly different things.  Let me try to
make myself clear.

From my experience with hacking around watchpoint-related code in
go32-nat.c, the question "are there enough resources to set
watchpoints?" is impossible to answer accurately, without knowing
*all* the watchpoints and all the hardware breakpoints that GDB will
want to insert before resuming.  The reason for this is that hardware
breakpoints and watchpoints consume the same resources (debug
registers), and OTOH several watchpoints might in some cases use up a
single debug register (if they watch the same address).

  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
> 

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