Since g:c223d3738832011ced54e8415fa218934aebd0e4 (https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=c223d3738832011ced54e8415fa218934aebd0e4), we have noticed that the new tests fail on arm: Running gdb:gdb.base/watchpoint-running.exp ... FAIL: gdb.base/watchpoint-running.exp: all-stop: hardware: watch global_var FAIL: gdb.base/watchpoint-running.exp: all-stop: hardware: watchpoint hit (timeout) FAIL: gdb.base/watchpoint-running.exp: non-stop: hardware: watch global_var FAIL: gdb.base/watchpoint-running.exp: non-stop: hardware: watchpoint hit (timeout) Running gdb:gdb.threads/signal-command-handle-nopass.exp ... FAIL: gdb.threads/signal-command-handle-nopass.exp: step-over no: signal SIGUSR1
From gdb.log: [...] PASS: gdb.base/watchpoint-running.exp: all-stop: hardware: values are different watch global_var Watchpoint 2: global_var (gdb) FAIL: gdb.base/watchpoint-running.exp: all-stop: hardware: watch global_var FAIL: gdb.base/watchpoint-running.exp: all-stop: hardware: watchpoint hit (timeout) [...] PASS: gdb.base/watchpoint-running.exp: non-stop: hardware: values are different watch global_var Watchpoint 2: global_var (gdb) FAIL: gdb.base/watchpoint-running.exp: non-stop: hardware: watch global_var FAIL: gdb.base/watchpoint-running.exp: non-stop: hardware: watchpoint hit (timeout) [...] (gdb) PASS: gdb.threads/signal-command-handle-nopass.exp: step-over no: thread 1 selected signal SIGUSR1 Continuing with signal SIGUSR1. Thread 1 "signal-command-" received signal SIGUSR1, User defined signal 1. __libc_do_syscall () at ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S:47 warning: 47 ../sysdeps/unix/sysv/linux/arm/libc-do-syscall.S: No such file or directory (gdb) FAIL: gdb.threads/signal-command-handle-nopass.exp: step-over no: signal SIGUSR1
Is this 32-bit or 64-bit ARM? I'm assuming 32-bit. > (gdb) FAIL: gdb.base/watchpoint-running.exp: all-stop: hardware: watch global_var > FAIL: gdb.base/watchpoint-running.exp: all-stop: hardware: watchpoint hit (timeout) It very much looks like the ARM Linux backend is buggy wrt to setting watchpoints. It was always possible to set watchpoints while threads are running. It just wasn't possible if the _current_ thread wasn't stopped. So it just looks like the testcase uncovered some pre-existing bug. The debug registers should be updated on all threads when the watchpoint is created, in the low_prepare_to_resume implementation, if the dregs were modified. arm_linux_insert_hw_breakpoint1 does mark the debug registers as modified, via update_registers_callback, and then forces a temporary pause. From a quick glance, the necessary pieces are in place. Still, for some reason, the watchpoint still doesn't trigger? Someone who is motivated to work on the ARM backend should look into that. Probably "set debug infrun 1" + "set debug linux-nat 1" would help understand what is going on. > FAIL: gdb.threads/signal-command-handle-nopass.exp: step-over no: signal SIGUSR1 I don't see how the commit in question could be related to this. It only touched the code that creates watchpoints, and this testcase does not create watchpoints.
Wait a second ... > watch global_var > Watchpoint 2: global_var > (gdb) FAIL: gdb.base/watchpoint-running.exp: all-stop: hardware: watch global_var ... this above shows that GDB inserted a software watchpoint, not a hardware watchpoint. Ah. Does that machine not have hardware watchpoints?
Probably the backend thinks this can't be honored with a hardware watchpoint.
There is only one watchpoint, and it is set on a 64-bit global variable.
I'll try to reproduce this. Watchpoints on 32-bit Arm have been a bit unreliable due to bugs in the kernel and particularities on the interface itself. There is also a compat layer with 32-bit-on-64-bit-systems that makes things a bit more difficult to reproduce.