This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: Hardware watchpoints; dealing with false triggers?
- From: "Eli Zaretskii" <eliz at is dot elta dot co dot il>
- To: orjan dot friberg at axis dot com
- Cc: gdb-patches at sources dot redhat dot com
- Date: Fri, 30 Nov 2001 20:33:02 +0200
- Subject: Re: Hardware watchpoints; dealing with false triggers?
- References: <Pine.SUN.3.91.1011129164553.14665E-100000@is> <3C07B6FE.BBFA048D@axis.com>
- Reply-to: Eli Zaretskii <eliz at is dot elta dot co dot 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.