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


[Sorry, pressed "Send" too soon...]

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

Current code tries to ask this question each time the user adds a
watchpoint.  Since there's no way to answer that question accurately,
I opted for the safe alternative: if there's *any* chance that a
watchpoint *could* be inserted, go32-nat.c says YES, and leaves the
final judgement to resume time.  The result is that the user could see
"cannot insert watchpoint" when she says "continue".  However, this is
better than refusing to accept a hw watchpoint when in fact it could
be inserted.

If we agree that it is impossible for the target to know whether a
given set of watchpoints can be inserted unless it knows about all the
breakpoints and watchpoints, we need a way for the GDB application
code to pass all that info, and hear the answer, before it resumes the
debuggee.

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