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: Daniel Jacobowitz <drow at false dot org>
- Cc: orjan dot friberg at axis dot com, gdb-patches at sources dot redhat dot com
- Date: Thu, 15 Apr 2004 11:12:18 +0200
- Subject: Re: Display of read/access watchpoints when HAVE_NONSTEPPABLE_WATCHPOINT
- References: <ur81oqb1c.fsf@elta.co.il> <407282F4.2080602@axis.com> <20040406142228.GA29473@nevyn.them.org>
- Reply-to: Eli Zaretskii <eliz at gnu dot org>
Sorry for a late response: I was travelling beyond the reach of my
email.
> Date: Tue, 6 Apr 2004 10:22:28 -0400
> From: Daniel Jacobowitz <drow@false.org>
>
> Presumably, the relevant part of the comment is the second half: "this
> is for targets which cannot set read-only watchpoints".
Yes. The x86 processors belong to that family, so we didn't just
change the mainline code for dome isoteric CPU.
> On the other hand, it does not sound like that code will work for
> targets which _can_ set read-only watchpoints.
Patches to make that work for those platforms are welcome.
However, it seems to me that the right thing to do is to fix the cited
code in bpstat_stop_status (and perhaps elsewhere in breakpoint.c) to
DTRT for the test program posted by Orjan, since it clearly should
work with i386 as well, and since this specific failure of GDB has
nothing to do with read-only vs read-write watchpoints.
> The patch was:
>
> 2000-03-21 Eli Zaretskii <eliz@is.elta.co.il>
>
> * breakpoint.c (bpstat_stop_status): Don't stop if a read
> watchpoint appears to break, but the watched value changed.
See the test program that reveals the original problem I wanted to
fix, and the ensuing discussion, here:
http://sources.redhat.com/ml/gdb-patches/2000-03/msg00174.html
Any suggested patch should not break what was fixed back then.
AFAIR, without the value-changed test, the rwatch watchpoints were
totally unusable on x86, they would simply fire every time the watched
variable is set. So simply removing the test is not the way to solve
this, IMHO.
Btw, a workaround for the case in point is to use awatch, but of
course if rwatch can be fixed to avoid failure here, it's a better
solution.