[PATCH] [gdb/testsuite] Fix FAIL in gdb.threads/sw-watchpoint-step-over-bp-with-threads.exp

[Tom de Vries <tdevries@suse.de>]

On x86_64-linux, I ran into the following FAIL:
...
(gdb) cont
Continuing.
[Switching to Thread 0x7ffff7cbe6c0 (LWP 3534988)]

Thread 2 "sw-watchpoint-s" hit Watchpoint 3: watched_global

Old value = 0
New value = 1
0x00007ffff7d514bf in futex_wait () at ../sysdeps/nptl/futex-internal.h:146
146       int err = lll_futex_timed_wait (futex_word, expected, NULL, private);
(gdb) PASS: $exp: target-non-stop=auto: displaced-stepping=auto: \
  continue to watchpoint
break 64
No compiled code for line 64 in the current file.
Make breakpoint pending on future shared library load? (y or [n]) n
(gdb) FAIL: $exp: target-non-stop=auto: displaced-stepping=auto: \
  gdb_breakpoint: set breakpoint at 64
...

[ The FAIL initially reproduced only under heavy system load (simulated using
stress -c $(grep -c ^processor: /proc/cpuinfo)), but then I found that
changing the delay in $srcfile from 1 second to 1 millisecond also reproduced
it fairly reliably.  Using this approach, I managed to reproduce both on
x86_64-linux and aarch64-linux. ]

The test-case tries to set a breakpoint at $srcfile:64, using just "64", but
that doesn't work because the inferior is not stopped in $srcfile.

This can be trivially fixed by using $srcfile:64 instead, and indeed, this is
what this patch does.

However, that fix is only correct if gdb is indeed allowed to report a stop in
thread 2.

This is a question I found difficult to answer.

I found some text in the docs [1] that seems related to the test-case
scenario:
...
Warning: In multi-threaded programs, software watchpoints have only limited
usefulness.  If GDB creates a software watchpoint, it can only watch the value
of an expression in a single thread.  If you are confident that the expression
can only change due to the current thread’s activity (and if you are also
confident that no other thread can become current), then you can use software
watchpoints as usual.  However, GDB may not notice when a non-current thread’s
activity changes the expression. (Hardware watchpoints, in contrast, watch an
expression in all threads.)
...

After reading this text, my impression was that gdb shouldn't report a stop in
thread 2, because:
- GDB "can only watch the value of an expression in a single thread",
- the expression can only change due the current thread's activity (thread 1),
  and
- thread 2 cannot become current, it just spins and there's no breakpoint set
  in the range where it spins.

However, in the test-case I came across the following text:
...
    # The final continue, with the software watchpoint set, so that
    # GDB single-steps all threads (if the target is non-stop).
...

Indeed, the test-case iterates over some dimensions:
...
foreach_with_prefix target-non-stop {auto on off} {
    foreach_with_prefix displaced-stepping {auto on off} {
	test ${target-non-stop} ${displaced-stepping}
    }
}
...
and disregarding the auto, the FAIL reproduces with both displaced-stepping on
and off, but only with target-non-stop on.

So we have the default non-stop off, and target-non-stop on.

The documentation says about this [2]:
...
set non-stop off, target operating in non-stop mode

When a thread hits a breakpoint, finishes a step, etc., the target does not
immediately stop all other threads.  If, while processing the event, infrun
decides the stop should be reported to the user, it then explicitly stops all
threads, just before presenting the stop to the user; otherwise, infrun
re-resumes the stopped thread.  This scenario is also called “all-stop on top
of non-stop”.
...

I was not able to deduce why in this situation and in presence of a software
watchpoint all threads should be single stepping, so I asked Claude Code.

It gave the following background information:
- in the pure all-stop case (set non-stop off, target operating in all-stop
  mode), in presence of a software watchpoint:
  - the current thread single-steps
  - the other threads stay stopped
  - consequently, only modifications by the current thread are detected,
- in the all-stop on non-stop case (set non-stop off, target operating in
  non-stop mode), in presence of a software watchpoint:
  - all threads single-step
  - consequently, modifications by any thread are detected, but it's not
    possible to attribute the modification to any specific thread, so gdb
    attributes it to the thread whose stop happens to be processed.

This adequately explains the behavior in the test-case.

I suspect that the warning text in the documentation needs updating, because
AFAICT it doesn't cover the "set non-stop off, target operating in non-stop
mode" behavior described above.

Tested on x86_64-linux.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=34280

[1] https://sourceware.org/gdb/current/onlinedocs/gdb.html/Set-Watchpoints.html
[2] https://sourceware.org/gdb/current/onlinedocs/gdb.html/Maintenance-Commands.html#index-maint-set-target_002dnon_002dstop-mode-_005bon_007coff_007cauto_005d
---
 .../gdb.threads/sw-watchpoint-step-over-bp-with-threads.exp     | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gdb/testsuite/gdb.threads/sw-watchpoint-step-over-bp-with-threads.exp b/gdb/testsuite/gdb.threads/sw-watchpoint-step-over-bp-with-threads.exp
index 3dac2b85987..bd520cd62dd 100644
--- a/gdb/testsuite/gdb.threads/sw-watchpoint-step-over-bp-with-threads.exp
+++ b/gdb/testsuite/gdb.threads/sw-watchpoint-step-over-bp-with-threads.exp
@@ -80,7 +80,7 @@ proc test {target-non-stop displaced-stepping} {
     # fail an assertion that checks that we never ask the target to
     # hardware single-step a thread when we have a software
     # single-step breakpoint set for that thread.
-    gdb_breakpoint [gdb_get_line_number "break here end"]
+    gdb_breakpoint $::srcfile:[gdb_get_line_number "break here end"]
     gdb_continue_to_breakpoint "end"
 }
 

base-commit: 95451ea43a7e2e4aa806ee7405e9167b2ee653c1
-- 
2.51.0