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: Orjan Friberg <orjan dot friberg at axis dot com>
- To: gdb-patches at sources dot redhat dot com
- Date: Tue, 06 Apr 2004 12:14:12 +0200
- Subject: Re: Display of read/access watchpoints when HAVE_NONSTEPPABLE_WATCHPOINT
- Organization: Axis Communications
- References: <ur81oqb1c.fsf@elta.co.il>
Eli Zaretskii wrote:
Anyway, from your description, it is quite clear that if a target
defines HAVE_NONSTEPPABLE_WATCHPOINT, GDB must call
target_stopped_data_address before it disables the watchpoint and
steps over it, or else the target end should store the necessary info
somewhere and deliver it when target_stopped_data_address is called.
In other words, it sounds like a bug.
I had missed a previous thread on the subject, initiated by Paul Koning
(starting at
http://sources.redhat.com/ml/gdb-patches/2003-05/msg00506.html). Paul
sent me a patch for 5.3 which no longer applies cleanly, and with his
blessings I'm trying to update his patch to the current CVS.
Doing that, I encountered a problem with read watchpoints (rwatch
command): in insert_breakpoints, before calling insert_bp_location, the
current value of the watched expression is read. Then in
bpstat_stop_status, when the watchpoint has hit, there's the following
code snippet:
case WP_VALUE_CHANGED:
if (b->type == bp_read_watchpoint)
{
/* Don't stop: read watchpoints shouldn't fire if
the value has changed. This is for targets
which cannot set read-only watchpoints. */
bs->print_it = print_it_noop;
bs->stop = 0;
continue;
}
++(b->hit_count);
break;
So, if we're "read watching" a variable that indeed has changed since we
read it before inserting it we decide not to stop. Here's another
example (foo is rwatched):
volatile int foo = 0;
int a;
a = foo; /* foo read; stops. */
foo = 1;
a = foo; /* foo read; doesn't stop because value changed. */
The "Don't stop" comment is consistent with the behaviour, so it seems
like this is intended. What am I missing here?
--
Orjan Friberg
Axis Communications