Re: Display of read/access watchpoints when HAVE_NONSTEPPABLE_WATCHPOINT

[Eli Zaretskii <eliz@gnu.org>]

> Date: Wed, 5 May 2004 09:44:30 -0400
> From: Paul Koning <pkoning@equallogic.com>
> 
>  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.

Would the suggested STOPPED_BY_WATCHPOINT patch work for the MIPS
remote stub?

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

But that is something the target-side code could handle, right?  I
mean, stopped_by_watchpoint has intimate knowledge about the target's
particulars, so it could fiddle the stop reason if it saw the
indication that a watchpoint fired _and_ that the most recent stop was
due to a single-step, right?

Failing that, we could have something like AUTO_STEPI_AFTER_WATCHPOINT
in higher-level code in GDB (infrun.c or breakpoint.c) to handle such
targets, but I generally think that the GDB application-level code
should not bother itself with target-specific peculiarities if we can
avoid that.