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

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

On 6/14/26 2:09 PM, Tom de Vries wrote:
> 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.
> 

I've pushed this.

Thanks,
- Tom

> 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