Re: Display of read/access watchpoints when HAVE_NONSTEPPABLE_WATCHPOINT

["Eli Zaretskii" <eliz@gnu.org>]

> Date: Fri, 16 Apr 2004 13:42:18 +0200
> From: Orjan Friberg <orjan.friberg@axis.com>
> 
> Orjan Friberg wrote:
> > 
> > 1. Add a check if the target cannot set "pure" read watchpoints to the 
> > b->type == bp_read_watchpoint check at WP_VALUE_CHANGED (my 
> > interpretation of Eli's suggestion).
> 
> On second thought, this actually is no good for a target which *can* set 
> pure read watchpoints.  If there's both a watch and an rwatch on a 
> variable that is written, we'll get a false read watchpoint hit.

How about if such targets would set a read/write (i.e. access)
watchpoint, and then use the same logic as i386: if the value didn't
change, don't announce the rwatch hit?  In effect, you would be
emulating i386 behavior.

That's a band-aid, I know.  But to get rid of this mess altogether,
the GDB's watchpoint processing will need to be thoroughly revamped.
In particular, instead of walking all the watchpoints armed only with
the address that caused the inferior to stop, we would need to have
the target to tell us exactly what watchpoint triggered, and why.
That would mean pushing most of the related logic in
bpstat_stop_status into the target/architecture vectors, leaving the
GDB's application level with only the higher-level API that
communicates with the lower-level layers via watchpoint handles of
some kind.

By contrast, the current GDB code for hardware-assisted watchpoints
grew up from the software watchpoints, whereby GDB would single-step
the program and after each step check whether the value of any of the
watched expressions changed.  This legacy clearly shows for quite some
time.