From: Vladimir Prus <ghost@cs.msu.su>
To: gdb@sources.redhat.com
Subject: read watchpoints ignored?
Date: Fri, 11 Nov 2005 13:22:00 -0000 [thread overview]
Message-ID: <200511111622.01337.ghost@cs.msu.su> (raw)
Hi,
I found a situation when read watchpoints are ignored by gdb. Consider this
program:
#include <stdio.h>
int a, b, c;
int main()
{
a = 10;
printf("Here I am\n");
b = a;
c = a;
return 0;
}
and this gdb session:
(gdb) b main
Breakpoint 1 at 0x80483a4: file rw.cpp, line 8.
(gdb) r
Starting program: /tmp/a.out
Breakpoint 1, main () at rw.cpp:8
8 a = 10;
(gdb) rwatch a
Hardware read watchpoint 2: a
(gdb) c
Continuing.
Hardware read watchpoint 2: a
Value = 10
0x080483bd in main () at rw.cpp:11
11 c = a;
Expected result: gdb stops on "b = a" line.
Actual result: gdb stops on "c = a".
Here's why it happens. When breakpoint is set, gdb reads the current value
of 'a', which is zero. After continue, a is assigned the value of '10', and
then first read watchpoint fires (on "b = a"). We arrive to
"bpstat_stop_status" (breakpoint.c), which has the following code:
else if (b->type == bp_read_watchpoint ||
b->type == bp_access_watchpoint)
{
...
if (found)
{
...
int e = catch_errors (watchpoint_check, bs, message,
RETURN_MASK_ALL);
switch (e)
{
.......
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;
}
Since value of 'a' was changed by the "a = 10" line, "watchpoint_check"
returns "WP_VALUE_CHANGED", and reporting of watchpoint is completely
suppressed.
Questions:
1. Is this a bug?
2. Can this bug be fixed by removing this inner
if (b->type == bp_read_wathcpoint)
statement? This will cause watchpoints to trigger more often
on those target that don't have "read-only watchpoints", but
there will be no risk of missing watchpoint. And I think missed
watchpoint is more harm then spurious watchpoint.
Opinions?
- Volodya
next reply other threads:[~2005-11-11 13:22 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-11 13:22 Vladimir Prus [this message]
2005-11-11 18:19 ` Eli Zaretskii
2005-11-13 16:45 ` Daniel Jacobowitz
2005-11-13 22:38 ` Eli Zaretskii
2005-11-14 2:43 ` Daniel Jacobowitz
2005-11-14 4:38 ` Eli Zaretskii
2005-11-14 14:42 ` Daniel Jacobowitz
2005-11-15 4:02 ` Eli Zaretskii
2005-11-14 10:10 ` Vladimir Prus
2005-11-14 14:41 ` Daniel Jacobowitz
2005-11-14 14:45 ` Daniel Jacobowitz
2005-11-15 4:02 ` Eli Zaretskii
2005-11-14 13:16 ` Johan Rydberg
2005-11-14 13:42 ` Vladimir Prus
2005-11-14 13:59 ` Johan Rydberg
2005-11-14 14:10 ` Vladimir Prus
2005-11-15 4:01 ` Eli Zaretskii
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200511111622.01337.ghost@cs.msu.su \
--to=ghost@cs.msu.su \
--cc=gdb@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox