[Bug testsuite/34280] [gdb/testsuite] FAIL: gdb.threads/sw-watchpoint-step-over-bp-with-threads.exp: target-non-stop=auto: displaced-stepping=auto: gdb_breakpoint: set breakpoint at 64

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

--- Comment #4 from Sourceware Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Tom de Vries <[email protected]>:

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

commit fbafe3b994c6f8f9778bab0b3160e9a21bfa211f
Author: Tom de Vries <[email protected]>
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

-- 
You are receiving this mail because:
You are on the CC list for the bug.