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

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

I've set some hardware watchpoints, the rerun the program, and noticed
that it didn't go anywhere, with gdb consuming all the CPU.

It appears that under some conditions HW watchpoints "degenerate" into
single-stepping. To reproduce on Linux/x86_64:


--- cut --- t.c ---
#include <stdlib.h>

#ifndef LIMIT
#define LIMIT 100000
#endif

int main()
{
    int i;
    for (i = 0; i < LIMIT; ++i)
      {
	int *ip = malloc(sizeof(int));
	*ip = i;
	if (i == LIMIT - 1)
	  abort();
      }
}
--- cut --- t.c ---

Using "GNU gdb (GDB) 6.8.50.20090821-cvs", I see this:

gcc -g t.c -DLIMIT=1000 && time gdb64-cvs -q -ex run -ex 'up 2' -ex 'print ip'
-ex 'watch *$1' -ex 'run' -ex quit ./a.out

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

Old value = <unreadable>
New value = 0
main () at t.c:13
13              *ip = i;

real    0m0.231s
user    0m0.148s
sys     0m0.024s


gcc -g t.c -DLIMIT=10000 && time gdb64-cvs -q -ex run -ex 'up 2' -ex 'print ip'
-ex 'watch *$1' -ex 'run' -ex quit ./a.out

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

Old value = <unreadable>
New value = 0
main () at t.c:13
13              *ip = i;

real    0m1.512s
user    0m1.060s
sys     0m0.340s


gcc -g t.c -DLIMIT=100000 && time gdb64-cvs -q -ex run -ex 'up 2' -ex 'print ip'
-ex 'watch *$1' -ex 'run' -ex quit ./a.out

Program received signal SIGABRT, Aborted.
0x00007ffff7ab0095 in raise () from /lib/libc.so.6
#2  0x000000000040051e in main () at t.c:15
15                abort();
$1 = (int *) 0x90e3f0
                                       <<< 15s delay here
Hardware watchpoint 1: *$1
Hardware watchpoint 1: *$1

Old value = <unreadable>
New value = 0
main () at t.c:13
13              *ip = i;

real    0m14.542s
user    0m11.733s
sys     0m2.644s


Why does it take 15s to do 100000 iterations with a HW watchpoint?
'set debug infrun 1' shows unending stream of:

infrun: prepare_to_wait
infrun: target_wait (-1, status) =
infrun:   18710 [process 18710],
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 = 0x7fffffffd9f0
infrun: no stepping, continue
infrun: resume (step=0, signal=0), trap_expected=0
infrun: prepare_to_wait
infrun: target_wait (-1, status) =
infrun:   18710 [process 18710],
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 = 0x7fffffffd9f0
infrun: no stepping, continue
infrun: resume (step=0, signal=0), trap_expected=0
...

-- 
           Summary: HW watchpoints silently degrade into SW ones
           Product: gdb
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: breakpoints
        AssignedTo: unassigned at sourceware dot org
        ReportedBy: ppluzhnikov at google dot com
                CC: gdb-prs at sourceware dot org
 GCC build triplet: x86_64-unknown-linux-gnu
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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.