Re: Display of read/access watchpoints when HAVE_NONSTEPPABLE_WATCHPOINT

[Paul Koning <pkoning@equallogic.com>]

>>>>> "Ulrich" == Ulrich Weigand <weigand@i1.informatik.uni-erlangen.de> writes:

 Ulrich> Mark Kettenis wrote:
 >> This patch breaks hardware watchpoints in SVR4-derived systems.
 >> Those systems don't provide target_stopped_data_address().  The
 >> default target_stopped_data_address() will always return zero,
 >> which means that triggered watchpoints aren't properly caught.
 >> This results in spurious SIGTRAPS.

 Ulrich> The patch also breaks s390(x), for exactly this reason.

 Ulrich> We don't define target_stopped_data_address, and *cannot* do
 Ulrich> so because the hardware doesn't provide this information.

Neither does MIPS, unless you disassemble the trapping instruction to
deduce the address.  That's what I've done in our MIPS remote gdb
stub.

 Ulrich> We do know whether a SIGTRAP was due to a (any) watchpoint or
 Ulrich> not, however, and define STOPPED_BY_WATCHPOINT to indicate
 Ulrich> this.

 Ulrich> (Since the hardware supports only write watchpoints, not read
 Ulrich> or access watchpoints, this should -and used to- be enough
 Ulrich> for gdb to find out what happened by manually checking
 Ulrich> watchpoint values.)

My experience was that the old code worked if you had only a
watchpoint active, but it would produce the wrong results if you had
both watchpoints and breakpoints active.  The reason was that the scan
for matching break/watch points would conclude that the target break
had happened due to a non-matching watchpoint and would proceed,
rather than break.

 Ulrich> The patch below uses STOPPED_BY_WATCHPOINT instead of
 Ulrich> target_stopped_data_address in bpstat_stop_status; this get
 Ulrich> s390(x) watchpoints back functional.

My memory is a little faded by now, but I think I tried that at first.

The trouble I ran into is that this doesn't work because (on remote
target support for MIPS anyway) the watchpoint handling does an
effective "stepi" after the watchpoint stop.  After that stepi,
stopped_by_watchpoint() would return false because the most recent
stop was due to a break (the stepi).  That's why
remote_stopped_data_address still returns non-zero if
stepped_after_stopped_by_watchpoint is set.

There may well be a better way to do this, but this is the reason why
I did it this way, as far as I can reconstruct it now.

 Ulrich> Alternatively, we could also make the
 Ulrich> target_stopped_data_address check only for read and access
 Ulrich> watch points, *not* for write watchpoints ...

That doesn't seem like a good idea.  Why would it be reasonable to
treat the two differently?

      paul