[00/11] Enable non-stop mode by default for remote targets

  From: "Bouhaouel, Mohamed" <mohamed.bouhaouel@intel.com>

This series makes remote targets operate in non-stop mode if the target
announces QNonStop support and 'maint set target-non-stop’ is set to
‘auto', aligning the behavior with the Linux native target.

When non-stop is forced on at startup, GDB has no selected thread when DAP
emits a 'continued' or 'stopped' event, and gdb.selected_thread() returns None.
The fix follows the DAP spec: default threadId to 0 for 'continued' (required)
and omit it for 'stopped' (optional) if no thread is selected.
We could not validate this against a real DAP-driven GUI, but the full
DAP testsuite passes.

- Open

'gdb.threads/current-lwp-dead.exp' fails intermittently with this series.
The test deliberately crafts a scenario where the previously-selected LWP has
already exited by the time a breakpoint hits in another LWP (using clone()
without CLONE_THREAD, so GDB still sees the new task as a thread of the same
inferior via PTRACE_EVENT_CLONE).  With a non-stop remote target, GDB
processes the parent's exit event while another LWP is being single-stepped,
and the resulting thread-state churn fails the test.

Bouhaouel, Mohamed (8):
  gdb, remote: fix assertion on reconnect to non-stop target
  gdb, remote: fix async handler assertion on reconnect to non-stop
    target
  gdb, remote: fix "info program" after reconnect to non-stop target
  gdb, remote: fix crash when accessing removed events
  gdb, testsuite: handle async close in monitor-exit-quit.exp
  gdb, testsuite: update attach-deleted-exec.exp to handle async
    messages
  gdb, testsuite: add kfails for step-over-process-exit.exp
  gdb, remote: implement always_non_stop_p for remote target

Markus Metzger (1):
  gdb, record: fix assertion when remote target is set to non-stop

Rohr, Stephan (2):
  gdb, remote: fix ptid matching for process-wide stop events
  gdb, dap: fix DAP events if no thread is selected

 gdb/python/lib/gdb/dap/events.py              | 15 ++++-
 gdb/record-full.c                             |  3 +-
 gdb/remote.c                                  | 59 ++++++++++++++-----
 .../gdb.base/attach-deleted-exec.exp          | 59 +++++++++++--------
 .../gdb.server/monitor-exit-quit.exp          |  9 ++-
 .../gdb.threads/step-over-process-exit.exp    |  6 ++
 6 files changed, 106 insertions(+), 45 deletions(-)
  

Kindly pinging.

Thanks!
--Mohamed

> -----Original Message-----
> From: Bouhaouel, Mohamed <mohamed.bouhaouel@intel.com>
> Sent: Monday, 18 May 2026 20:33
> To: gdb-patches@sourceware.org
> Cc: Bouhaouel, Mohamed <mohamed.bouhaouel@intel.com>; Rohr, Stephan
> <stephan.rohr@intel.com>; Metzger, Markus T
> <markus.t.metzger@intel.com>
> Subject: [PATCH 00/11] Enable non-stop mode by default for remote targets
> 
> From: "Bouhaouel, Mohamed" <mohamed.bouhaouel@intel.com>
> 
> This series makes remote targets operate in non-stop mode if the target
> announces QNonStop support and 'maint set target-non-stop’ is set to
> ‘auto', aligning the behavior with the Linux native target.
> 
> When non-stop is forced on at startup, GDB has no selected thread when
> DAP
> emits a 'continued' or 'stopped' event, and gdb.selected_thread() returns
> None.
> The fix follows the DAP spec: default threadId to 0 for 'continued' (required)
> and omit it for 'stopped' (optional) if no thread is selected.
> We could not validate this against a real DAP-driven GUI, but the full
> DAP testsuite passes.
> 
> - Open
> 
> 'gdb.threads/current-lwp-dead.exp' fails intermittently with this series.
> The test deliberately crafts a scenario where the previously-selected LWP has
> already exited by the time a breakpoint hits in another LWP (using clone()
> without CLONE_THREAD, so GDB still sees the new task as a thread of the
> same
> inferior via PTRACE_EVENT_CLONE).  With a non-stop remote target, GDB
> processes the parent's exit event while another LWP is being single-stepped,
> and the resulting thread-state churn fails the test.
> 
> Bouhaouel, Mohamed (8):
>   gdb, remote: fix assertion on reconnect to non-stop target
>   gdb, remote: fix async handler assertion on reconnect to non-stop
>     target
>   gdb, remote: fix "info program" after reconnect to non-stop target
>   gdb, remote: fix crash when accessing removed events
>   gdb, testsuite: handle async close in monitor-exit-quit.exp
>   gdb, testsuite: update attach-deleted-exec.exp to handle async
>     messages
>   gdb, testsuite: add kfails for step-over-process-exit.exp
>   gdb, remote: implement always_non_stop_p for remote target
> 
> Markus Metzger (1):
>   gdb, record: fix assertion when remote target is set to non-stop
> 
> Rohr, Stephan (2):
>   gdb, remote: fix ptid matching for process-wide stop events
>   gdb, dap: fix DAP events if no thread is selected
> 
>  gdb/python/lib/gdb/dap/events.py              | 15 ++++-
>  gdb/record-full.c                             |  3 +-
>  gdb/remote.c                                  | 59 ++++++++++++++-----
>  .../gdb.base/attach-deleted-exec.exp          | 59 +++++++++++--------
>  .../gdb.server/monitor-exit-quit.exp          |  9 ++-
>  .../gdb.threads/step-over-process-exit.exp    |  6 ++
>  6 files changed, 106 insertions(+), 45 deletions(-)
> 
> --
> 2.43.0

Intel Deutschland GmbH

Registered Address: Dornacher Strasse 1, 85622 Feldkirchen, Germany
Tel: +49 89 991 430, www.intel.de
Managing Directors: Harry Demas, Jeffrey Schneiderman, Yin Chong Sorrell
Chairperson of the Supervisory Board: Nicole Lau
Registered Seat: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928
  

On 2026-05-18 19:32, Mohamed Bouhaouel wrote:
> From: "Bouhaouel, Mohamed" <mohamed.bouhaouel@intel.com>
> 
> This series makes remote targets operate in non-stop mode if the target
> announces QNonStop support and 'maint set target-non-stop’ is set to
> ‘auto', aligning the behavior with the Linux native target.

This wasn't done before for a reason.  It's that 'maint set target-non-stop on’
does not support all the features the all-stop variant of the remote protocol.

Specifically, off the top of my head:

  - there is no alternative to the O packet.  Those can be sent while the
    target is running as if they were a stop reply, but that doesn't work
    in non-stop mode.

    See remote_target::wait_as:

       case 'O':		/* Console output.  */

  - remote file I/O support does not work.  Similar to the O packet.

    See remote_target::wait_as:

       case 'F':		/* File-I/O request.  */

  - packet efficiency.  With non-stop, GDB suspends and resumes each
    thread individually.

     - on the resumption side, that is mitigated by GDB coalescing
       vCont packets.  when you e.g. "continue", gdb core does one
       target_resume call per thread, but the remote target backend
       does not resume the thread immediately.  Instead, it defers
       the resume until infrun calls target_commit_resumed().

     - on the stopping side, however, there is no support for aggregation.
       The server reports each thread stop with its own separate stop reply
       notification.


So it's plausible that there may some stubs out there that do support
non-stop mode, but they also support e.g., file I/O.  Enabling non-stop by
default for those might not be the correct choice.

Or maybe the performance degrades visibly.  Maybe there are some
mitigating factors, like, maybe it won't matter that much if we have
displaced stepping.

My point is, this needs to be a considered change, not just "to align with linux".

Pedro Alves