Re: Hardware watchpoints; dealing with false triggers?

["Eli Zaretskii" <eliz@is.elta.co.il>]

> Date: Fri, 30 Nov 2001 17:42:38 +0100
> From: Orjan Friberg <orjan.friberg@axis.com>
> 
> Maybe I should clarify that I'm not talking about the x86, but a
> hypothetical target whose watchpoint mechanism would function this way. 

Yes, I guessed that much.

> > > Now, say a there's a read of wp1's byte 0.  The hardware would trigger,
> > > but it would be a false trigger.  Gdb would somehow have to find out the
> > > actual address that was read and if it was found to be outside of the
> > > variable's range it would not trigger the watchpoint.
> > 
> > You can't do that, at least not with x86 debug registers: when a
> > watchpoint triggers, you don't know what byte of its covered memory was
> > written to.  All you know is that memory covered by a specific register
> > was written.
> 
> Ok, but say that the actual address is shipped with the register packet
> when the target stops so that gdb in fact knows what address was
> actually read/written.  I'm thinking gdb could compare that address with
> the watchpoints, and just send the target on its way if the address is
> outside the watched ranges.

This can be done.  The low-level target end is repsonsible to tell
GDB whether a watchpoint triggered, and at what address.  So given
enough information from your target, you could write the low-level
watchpoint code to DTRT.

> And this is the key issue: could the interface to the target-specific
> code be extended to handle the concept of "actual watchpoint address"? 

We already have this: it's called target_stopped_data_address.
breakpoint.c uses this macro to see which watchpoint, if any,
triggered.