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

[Tom de Vries]

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=fbafe3b994c6f8f9778bab0b3160e9a21bfa211f

commit fbafe3b994c6f8f9778bab0b3160e9a21bfa211f
Author: Tom de Vries <tdevries@suse.de>
Date:   Mon Jul 13 15:29:14 2026 +0200

    [gdb/testsuite] Fix FAIL in gdb.threads/sw-watchpoint-step-over-bp-with-threads.exp
    
    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

Diff:
---
 gdb/testsuite/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"
 }