This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: Display of read/access watchpoints when HAVE_NONSTEPPABLE_WATCHPOINT
- From: Eli Zaretskii <eliz at gnu dot org>
- To: Paul Koning <pkoning at equallogic dot com>
- Cc: weigand at i1 dot informatik dot uni-erlangen dot de, orjan dot friberg at axis dot com,kettenis at chello dot nl, gdb-patches at sources dot redhat dot com,drow at false dot org
- Date: 06 May 2004 08:10:22 +0200
- Subject: Re: Display of read/access watchpoints when HAVE_NONSTEPPABLE_WATCHPOINT
- References: <200405042208.AAA07379@faui1d.informatik.uni-erlangen.de> <16536.61374.770000.659411@gargle.gargle.HOWL>
- Reply-to: Eli Zaretskii <eliz at gnu dot 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.