[Bug breakpoints/10557] HW watchpoints silently degrade into SW ones

["ppluzhnikov at google dot com" <sourceware-bugzilla at sourceware dot org>]

------- Additional Comments From ppluzhnikov at google dot com  2010-08-25 23:02 -------
(In reply to comment #5)

> > Looks like something is single-stepping :-(
> 
> I don't think it is.  Go back to using "watch", reenable
> "set debug infrun 1", and confirm whether see a stream of
> things like these:
> 
> > infrun: TARGET_WAITKIND_STOPPED
> > infrun: stop_pc = 0x400507
> > infrun: stopped by watchpoint
> > infrun: stopped data address = 0x7fffffffd9f0
> > infrun: no stepping, continue
> > infrun: resume (step=0, signal=0), trap_expected=0
> 
> If you don't see "resume (step=1,...", then there's no single-stepping.

Confirmed: I don't.

> "stopped by watchpoint" means that the target thinks the thread hit
> a watchpoint (because the debug registers claim so).
> But I now notice something: "0x7fffffffd9f0" is a suspicious
> address, and it does not look like 'i'.  Is that a stack address?

Yes, it's &ip:

infrun: clear_proceed_status_thread (process 29122)
infrun: proceed (addr=0xffffffffffffffff, signal=144, step=0)
infrun: resume (step=0, signal=0), trap_expected=0
infrun: wait_for_inferior (treat_exec_as_sigtrap=0)
infrun: target_wait (-1, status) =
infrun:   29122 [process 29122],
infrun:   status->kind = stopped, signal = SIGTRAP
infrun: infwait_normal_state
infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x400507
infrun: stopped by watchpoint
infrun: stopped data address = 0x7fffffffd8d0
infrun: BPSTAT_WHAT_STOP_NOISY
infrun: stop_stepping
Hardware access (read/write) watchpoint 1: *$1

Value = <unreadable>
Hardware access (read/write) watchpoint 1: *$1

Value = <unreadable>
main () at t.c:13
13              *ip = i;
(gdb) p &i
$2 = (int *) 0x7fffffffd8dc
(gdb) p &ip
$3 = (int **) 0x7fffffffd8d0

> That might explain why does the access watchpoint cause a stop,
> only to then not be able to evaluate the expression (<unreadable>).
> I sounds like gdb thought it needed to set a watchpoint on &i to be
> able to watch your expression?

Good guess.

But if I use 'watch *(int*)0x601010' instead of 'watch *$1',
things get *much* worse, and GDB does start stepping:

gcc -g t.c -DLIMIT=1 && /usr/bin/time gdb64-cvs -q -ex run -ex 'up 2' -ex 'print
ip' -ex 'watch *(int*)0x90e3f0' -ex run -ex q  ./a.out
Reading symbols from /tmp/pr10557/a.out...done.

Program received signal SIGABRT, Aborted.
0x00007ffff7ab0095 in raise () from /lib/libc.so.6
#2  0x000000000040051b in main () at t.c:15
15                abort();
$1 = (int *) 0x601010
Watchpoint 1: *(int*)0x601010

Program received signal SIGABRT, Aborted.
0x00007ffff7ab0095 in raise () from /lib/libc.so.6
5.83user 4.71system 0:10.68elapsed 98%CPU (0avgtext+0avgdata 0maxresident)k


Things to note above: 'Watchpoint 1' instead of 'Hardware watchpoint 1',
and much slower execution even with just one iteration of the loop.

Setting 'debug infrun' confirms that GDB is single-stepping in that case:

infrun: TARGET_WAITKIND_STOPPED
infrun: stop_pc = 0x7ffff7df4b73
infrun: no stepping, continue
infrun: resume (step=1, signal=0), trap_expected=0
infrun: prepare_to_wait
infrun: target_wait (-1, status) =
infrun:   6262 [process 6262],
infrun:   status->kind = stopped, signal = SIGTRAP
infrun: infwait_normal_state
...


When I do the watch manually, I can see the HW degrade into W (which is
why I filed this bug in the first place):

gdb64-cvs -q ./a.out
Reading symbols from /tmp/pr10557/a.out...done.
(gdb) r

Program received signal SIGABRT, Aborted.
0x00007ffff7ab0095 in raise () from /lib/libc.so.6
(gdb) up 2
#2  0x000000000040051b in main () at t.c:15
15                abort();
(gdb) p ip
$1 = (int *) 0x601010
(gdb) watch *(int*)0x601010
Hardware watchpoint 1: *(int*)0x601010
(gdb) r

   ... long delay here; note soft watchpoint below ...

Watchpoint 1: *(int*)0x601010

Old value = <unreadable>
New value = 0
0x00007ffff7b4e360 in brk () from /lib/libc.so.6
(gdb) q


-- 


http://sourceware.org/bugzilla/show_bug.cgi?id=10557

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.