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

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

[Mohamed Bouhaouel]

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

[PATCH 01/11] gdb, record: fix assertion when remote target is set to non-stop

[Mohamed Bouhaouel]

From: Markus Metzger <markus.t.metzger@intel.com>

When forcing the remote target to non-stop via 'maint set target-non-stop
on', reverse tests start failing with

    (gdb) .../gdb/remote.c:7561: internal-error: resume: Assertion `scope_ptid == inferior_ptid' failed.

This is caused by the record-full target doing one additional step after
receiving a single-step trap event.  That additional step is done on the
wait ptid instead of on the event ptid.  Fix it.
---
 gdb/record-full.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gdb/record-full.c b/gdb/record-full.c
index 69d2c100e57..fbb45c84931 100644
--- a/gdb/record-full.c
+++ b/gdb/record-full.c
@@ -1290,7 +1290,8 @@ record_full_wait_1 (struct target_ops *ops,
 				    "Process record: record_full_wait "
 				    "issuing one more step in the "
 				    "target beneath\n");
-		      ops->beneath ()->resume (ptid, step, GDB_SIGNAL_0);
+		      ops->beneath ()->resume (inferior_ptid, step,
+					       GDB_SIGNAL_0);
 		      proc_target->commit_resumed_state = true;
 		      proc_target->commit_resumed ();
 		      proc_target->commit_resumed_state = false;
-- 
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

Re: [PATCH 01/11] gdb, record: fix assertion when remote target is set to non-stop

[Andrew Burgess]

Mohamed Bouhaouel <mohamed.bouhaouel@intel.com> writes:

> From: Markus Metzger <markus.t.metzger@intel.com>
>
> When forcing the remote target to non-stop via 'maint set target-non-stop
> on', reverse tests start failing with
>
>     (gdb) .../gdb/remote.c:7561: internal-error: resume: Assertion `scope_ptid == inferior_ptid' failed.
>
> This is caused by the record-full target doing one additional step after
> receiving a single-step trap event.  That additional step is done on the
> wait ptid instead of on the event ptid.  Fix it.
> ---
>  gdb/record-full.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

I notice there's no new test here.

My guess is that this fixes an issue that will show up in some test once
patch #11 is merged.  Please could you include the details of which test
exposes this issue so it's easy to review this patch.

I've had a look at the next couple of patches and I think this same
feedback applies to them to.  I suspect (but have not checked) this
probably applies to patches #1 to #10.

Thanks,
Andrew

>
> diff --git a/gdb/record-full.c b/gdb/record-full.c
> index 69d2c100e57..fbb45c84931 100644
> --- a/gdb/record-full.c
> +++ b/gdb/record-full.c
> @@ -1290,7 +1290,8 @@ record_full_wait_1 (struct target_ops *ops,
>  				    "Process record: record_full_wait "
>  				    "issuing one more step in the "
>  				    "target beneath\n");
> -		      ops->beneath ()->resume (ptid, step, GDB_SIGNAL_0);
> +		      ops->beneath ()->resume (inferior_ptid, step,
> +					       GDB_SIGNAL_0);
>  		      proc_target->commit_resumed_state = true;
>  		      proc_target->commit_resumed ();
>  		      proc_target->commit_resumed_state = false;
> -- 
> 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

RE: [PATCH 01/11] gdb, record: fix assertion when remote target is set to non-stop

[Bouhaouel, Mohamed]

Hi Andrew,

Thanks for your feedback!

I submitted a new version addressing your comment.

https://sourceware.org/pipermail/gdb-patches/2026-June/227945.html
https://sourceware.org/pipermail/gdb-patches/2026-June/227955.html

V2 patches are split across two series due to an SMTP authentication failure
that occurred mid-submission.

Regards,
--Mohamed

> -----Original Message-----
> From: Andrew Burgess <aburgess@redhat.com>
> Sent: Wednesday, 10 June 2026 17:49
> To: Bouhaouel, Mohamed <mohamed.bouhaouel@intel.com>; 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: Re: [PATCH 01/11] gdb, record: fix assertion when remote target is
> set to non-stop
> 
> Mohamed Bouhaouel <mohamed.bouhaouel@intel.com> writes:
> 
> > From: Markus Metzger <markus.t.metzger@intel.com>
> >
> > When forcing the remote target to non-stop via 'maint set target-non-stop
> > on', reverse tests start failing with
> >
> >     (gdb) .../gdb/remote.c:7561: internal-error: resume: Assertion `scope_ptid
> == inferior_ptid' failed.
> >
> > This is caused by the record-full target doing one additional step after
> > receiving a single-step trap event.  That additional step is done on the
> > wait ptid instead of on the event ptid.  Fix it.
> > ---
> >  gdb/record-full.c | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> I notice there's no new test here.
> 
> My guess is that this fixes an issue that will show up in some test once
> patch #11 is merged.  Please could you include the details of which test
> exposes this issue so it's easy to review this patch.
> 
> I've had a look at the next couple of patches and I think this same
> feedback applies to them to.  I suspect (but have not checked) this
> probably applies to patches #1 to #10.
> 
> Thanks,
> Andrew
> 
> >
> > diff --git a/gdb/record-full.c b/gdb/record-full.c
> > index 69d2c100e57..fbb45c84931 100644
> > --- a/gdb/record-full.c
> > +++ b/gdb/record-full.c
> > @@ -1290,7 +1290,8 @@ record_full_wait_1 (struct target_ops *ops,
> >  				    "Process record: record_full_wait "
> >  				    "issuing one more step in the "
> >  				    "target beneath\n");
> > -		      ops->beneath ()->resume (ptid, step, GDB_SIGNAL_0);
> > +		      ops->beneath ()->resume (inferior_ptid, step,
> > +					       GDB_SIGNAL_0);
> >  		      proc_target->commit_resumed_state = true;
> >  		      proc_target->commit_resumed ();
> >  		      proc_target->commit_resumed_state = false;
> > --
> > 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

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

[PATCH 02/11] gdb, remote: fix assertion on reconnect to non-stop target

[Mohamed Bouhaouel]

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

When reconnecting to a non-stop remote target, threads may retain stale
internal state from the previous connection (e.g., THREAD_INT_RUNNING).
This causes an assertion failure in
thread_info::set_pending_waitstatus(), which requires the thread to be
in THREAD_INT_STOPPED or THREAD_INT_RESUMED_PENDING_STATUS state.

Fix by setting thread's states before calling set_pending_waitstatus ()
in process_initial_stop_replies ().

Scenario:
    - Connect to non-stop remote target with running threads.
    - Disconnect (threads remain in THREAD_INT_RUNNING state).
    - Reconnect to same target.
    - process_initial_stop_replies() processes stop events.
    - Assertion fails when trying to set pending waitstatus on thread still
      marked as THREAD_INT_RUNNING.
---
 gdb/remote.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/gdb/remote.c b/gdb/remote.c
index 735774903f3..4bdbf4aeb08 100644
--- a/gdb/remote.c
+++ b/gdb/remote.c
@@ -5237,12 +5237,13 @@ remote_target::process_initial_stop_replies (int from_tty)
 	  ws.set_stopped (sig);
 	}
 
+      set_internal_state (this, event_ptid, THREAD_INT_STOPPED);
+      set_state (this, event_ptid, THREAD_STOPPED);
+
       if (ws.kind () != TARGET_WAITKIND_STOPPED
 	  || ws.sig () != GDB_SIGNAL_0)
 	evthread->set_pending_waitstatus (ws);
 
-      set_internal_state (this, event_ptid, THREAD_INT_STOPPED);
-      set_state (this, event_ptid, THREAD_STOPPED);
       get_remote_thread_info (evthread)->set_not_resumed ();
     }
 
-- 
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

[PATCH 03/11] gdb, remote: fix async handler assertion on reconnect to non-stop target

[Mohamed Bouhaouel]

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

When reconnecting to a non-stop remote target during
process_initial_stop_replies (), the code attempts to mark an async event
handler before async mode is enabled.  This causes an assertion failure
in remote_state::mark_async_event_handler (), which requires the serial
connection to be in async mode (is_async_p () == true).

Fix by changing the condition in queued_stop_reply () from
target_can_async_p () to target_is_async_p (), matching the pattern used
in push_stop_reply ().  When async mode is later enabled, the event
handler will be marked then.

Scenario:
    - Connect to non-stop remote target.
    - Thread receives signal (e.g., SIGUSR1) and stops.
    - Disconnect and reconnect.
    - Assertion fails because mark_async_event_handler () requires
      is_async_p ().
---
 gdb/remote.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gdb/remote.c b/gdb/remote.c
index 4bdbf4aeb08..b7ccd72829b 100644
--- a/gdb/remote.c
+++ b/gdb/remote.c
@@ -8385,7 +8385,7 @@ remote_target::queued_stop_reply (ptid_t ptid)
   remote_state *rs = get_remote_state ();
   stop_reply_up r = remote_notif_remove_queued_reply (ptid);
 
-  if (!rs->stop_reply_queue.empty () && target_can_async_p ())
+  if (!rs->stop_reply_queue.empty () && target_is_async_p ())
     {
       /* There's still at least an event left.  */
       rs->mark_async_event_handler ();
-- 
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

[PATCH 04/11] gdb, remote: fix "info program" after reconnect to non-stop target

[Mohamed Bouhaouel]

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

After reconnecting to a non-stop remote target that has stopped threads,
"info program" incorrectly reports "The program being debugged is not
being run" instead of showing the stop information. This happens because
the previous_thread global is not updated when processing initial stop
replies.

Fix by calling update_previous_thread () after set_last_target_status ()
in print_one_stopped_thread ().

Scenario:
    - Connect to non-stop remote target
    - Thread receives signal (e.g., SIGUSR1) and stops
    - Disconnect and reconnect
    - "info program" reports "not being run" (FAIL)
---
 gdb/remote.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gdb/remote.c b/gdb/remote.c
index b7ccd72829b..a73362a26ee 100644
--- a/gdb/remote.c
+++ b/gdb/remote.c
@@ -5165,6 +5165,7 @@ remote_target::print_one_stopped_thread (thread_info *thread)
 
   /* For "info program".  */
   set_last_target_status (this, thread->ptid, ws);
+  update_previous_thread ();
 
   if (ws.kind () == TARGET_WAITKIND_STOPPED)
     {
-- 
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

[PATCH 05/11] gdb, remote: fix crash when accessing removed events

[Mohamed Bouhaouel]

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

Dereferencing events after calling std::remove_if causes GDB to crash
due to accessing invalidated iterators.  Fix by logging events in
std::remove_if.
---
 gdb/remote.c | 25 ++++++++++++++-----------
 1 file changed, 14 insertions(+), 11 deletions(-)

diff --git a/gdb/remote.c b/gdb/remote.c
index a73362a26ee..94ea4466c17 100644
--- a/gdb/remote.c
+++ b/gdb/remote.c
@@ -8314,17 +8314,20 @@ remote_target::discard_pending_stop_replies (struct inferior *inf)
 
   /* Discard the stop replies we have already pulled with
      vStopped.  */
-  auto iter = std::remove_if (rs->stop_reply_queue.begin (),
-			      rs->stop_reply_queue.end (),
-			      [=] (const stop_reply_up &event)
-			      {
-				return event->ptid.pid () == inf->pid;
-			      });
-  for (auto it = iter; it != rs->stop_reply_queue.end (); ++it)
-    remote_debug_printf
-      ("discarding queued stop reply: ptid: %s, ws: %s\n",
-       (*it)->ptid.to_string().c_str(),
-       (*it)->ws.to_string ().c_str ());
+  auto iter
+    = std::remove_if (rs->stop_reply_queue.begin (),
+		      rs->stop_reply_queue.end (),
+		      [=] (const stop_reply_up &event)
+		      {
+			if (event->ptid.pid () != inf->pid)
+			  return false;
+
+			remote_debug_printf
+			  ("discarding queued stop reply: ptid: %s, ws: %s\n",
+			   event->ptid.to_string ().c_str (),
+			   event->ws.to_string ().c_str ());
+			return true;
+		      });
   rs->stop_reply_queue.erase (iter, rs->stop_reply_queue.end ());
 }
 
-- 
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

[PATCH 06/11] gdb, remote: fix ptid matching for process-wide stop events

[Mohamed Bouhaouel]

From: "Rohr, Stephan" <stephan.rohr@intel.com>

If an inferior call results in a process event for a non-stop remote
target, GDB does not properly handle the event but is hanging.  This
reproduces with 'gdb.base/exit-in-condition.exp'.

Because GDB is evaluating a breakpoint condition, the corresponding
inferior call is evaluated w.r.t. the ptid of the current thread.
gdbserver sends a process exit event; the event is not matched by the
thread PTID and GDB hangs.

Fix this by matching a process event in 'stop_reply_queue' if there is
no matching thread event.  This ensures a thread event is prioritized
if both a thread event and a process event are queued and preserves the
current behavior.
---
 gdb/remote.c | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/gdb/remote.c b/gdb/remote.c
index 94ea4466c17..92fe518c6de 100644
--- a/gdb/remote.c
+++ b/gdb/remote.c
@@ -8363,6 +8363,20 @@ remote_target::remote_notif_remove_queued_reply (ptid_t ptid)
 			    {
 			      return event->ptid.matches (ptid);
 			    });
+
+  /* Match process events if PTID is a thread and there is no matching event
+     queued.  Prioritize thread events to preserve the existing behavior.  */
+  if (iter == rs->stop_reply_queue.end ()
+      && ptid != minus_one_ptid
+      && !ptid.is_pid ())
+    iter = std::find_if (rs->stop_reply_queue.begin (),
+			 rs->stop_reply_queue.end (),
+			 [=] (const stop_reply_up &event)
+			 {
+			   return (event->ptid.is_pid ()
+			     && event->ptid.pid () == ptid.pid ());
+			 });
+
   stop_reply_up result;
   if (iter != rs->stop_reply_queue.end ())
     {
-- 
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

[PATCH 07/11] gdb, dap: fix DAP events if no thread is selected

[Mohamed Bouhaouel]

From: "Rohr, Stephan" <stephan.rohr@intel.com>

The DAP protocol requires a thread-id for a continue event.  It is
optional for the stopped event.  If we force the remote target to run in
non-stop mode, i.e., "-iex maint set target-non-stop on", GDB does not
have a thread selected.  Default to '0' for continue events in this
case.  Omit the 'threadID' for stopped events if no thread is selected.
---
 gdb/python/lib/gdb/dap/events.py | 15 ++++++++++++---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/gdb/python/lib/gdb/dap/events.py b/gdb/python/lib/gdb/dap/events.py
index 27e3b5ab8bc..85e672b4c9e 100644
--- a/gdb/python/lib/gdb/dap/events.py
+++ b/gdb/python/lib/gdb/dap/events.py
@@ -138,10 +138,14 @@ def _cont(event):
         log("_suppress_cont case")
         _suppress_cont = False
     else:
+        thread = gdb.selected_thread()
+
+        # We may not have a selected thread if the target is running in
+        # non-stop mode.  Default to '0' in this case.
         send_event(
             "continued",
             {
-                "threadId": gdb.selected_thread().global_num,
+                "threadId": thread.global_num if thread else 0,
                 "allThreadsContinued": True,
             },
         )
@@ -213,9 +217,11 @@ def _on_stop(event):
     if hasattr(event, "details"):
         log("   details: " + repr(event.details))
     obj = {
-        "threadId": gdb.selected_thread().global_num,
         "allThreadsStopped": True,
     }
+    # The thread-id parameter is optional for stopped events.
+    if gdb.selected_thread():
+        obj["threadId"] = gdb.selected_thread().global_num
     if isinstance(event, gdb.BreakpointEvent):
         obj["hitBreakpointIds"] = [x.number for x in event.breakpoints]
     if hasattr(event, "details") and "finish-value" in event.details:
@@ -266,11 +272,14 @@ def _on_inferior_call(event):
         if not _infcall_was_running and inferior_running:
             inferior_running = False
             obj = {
-                "threadId": gdb.selected_thread().global_num,
                 "allThreadsStopped": True,
                 # DAP says any string is ok.
                 "reason": "function call",
             }
+            # The thread-id parameter is optional for stopped events.
+            if gdb.selected_thread():
+                obj["threadId"] = gdb.selected_thread().global_num
+
             global _expected_pause
             _expected_pause = False
             send_event("stopped", obj)
-- 
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

[PATCH 08/11] gdb, testsuite: handle async close in monitor-exit-quit.exp

[Mohamed Bouhaouel]

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

With non-stop remote targets, the "Remote connection closed"
notification arrives asynchronously after "monitor exit" and may appear
while processing the quit command, causing test failures.

Fix by using "with confirm off -- quit" and handling the async
notification in the quit sequence.
---
 gdb/testsuite/gdb.server/monitor-exit-quit.exp | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/gdb/testsuite/gdb.server/monitor-exit-quit.exp b/gdb/testsuite/gdb.server/monitor-exit-quit.exp
index cb90169ef0c..f0db907576e 100644
--- a/gdb/testsuite/gdb.server/monitor-exit-quit.exp
+++ b/gdb/testsuite/gdb.server/monitor-exit-quit.exp
@@ -50,11 +50,16 @@ set gdbserver_gdbport [lindex $res 1]
 gdb_target_cmd $gdbserver_protocol $gdbserver_gdbport
 
 gdb_test_no_output "monitor exit"
-gdb_test_no_output "set confirm off"
 
 set do_cleanup 1
 
-gdb_test_multiple "quit" "" {
+gdb_test_multiple "with confirm off -- quit" "" {
+    -re -wrap "Remote connection closed.*" {
+	# With non-stop remote targets, the "Remote connection closed"
+	# notification is delivered asynchronously and may appear while
+	# processing the quit command.
+	exp_continue
+    }
     -re -wrap "" {
 	fail "$gdb_test_name (prompt)"
 	# Let default_gdb_exit do the cleanup.
-- 
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

[PATCH 09/11] gdb, testsuite: update attach-deleted-exec.exp to handle async messages

[Mohamed Bouhaouel]

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

With non-stop targets, async thread notifications can appear between
output lines during attach.  Also, multiple "Reading symbols from"
messages are printed, so we need to specifically match the /proc/
path to capture the correct filename.

Output example on a non-stop remote target:

  (gdb) attach 33604
  Attaching to process 33604
  [New Thread 33604.33604 (id 1)]
  Reading symbols from /proc/33604/exe...
  Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...
  Reading symbols from /usr/lib/debug/.build-id/8e/9fd827446c24067541ac5390e6f527fb5947bb.debug...
  Reading symbols from /lib64/ld-linux-x86-64.so.2...
  Reading symbols from /usr/lib/debug/.build-id/da/07864eb4c1b06504b8688d25d7e84759fe708d.debug...
  [Switching to Thread 33604.33604]
  0x00007c9166eeca7a in __GI___clock_nanosleep ...
---
 .../gdb.base/attach-deleted-exec.exp          | 59 +++++++++++--------
 1 file changed, 34 insertions(+), 25 deletions(-)

diff --git a/gdb/testsuite/gdb.base/attach-deleted-exec.exp b/gdb/testsuite/gdb.base/attach-deleted-exec.exp
index 61ee8647c9c..71b1788a283 100644
--- a/gdb/testsuite/gdb.base/attach-deleted-exec.exp
+++ b/gdb/testsuite/gdb.base/attach-deleted-exec.exp
@@ -45,26 +45,29 @@ clean_restart
 
 # Attach.  GDB should spot that the executable is gone and fallback to
 # use /proc/PID/exe.
-set test "attach to process with deleted executable"
-set re \
-    [multi_line \
-	 "Attaching to process $decimal" \
-	 "Reading symbols from (\[^\r\n\]+)[string_to_regexp ...]" \
-	 ".*"]
-set filename ""
-gdb_test_multiple "attach $testpid" $test {
-    -re -wrap $re {
-	set filename $expect_out(1,string)
-	pass $gdb_test_name
+set attached_pid "no pid"
+gdb_test_multiple "attach $testpid" "attach to process with deleted executable" {
+    -re "Attaching to process $decimal\r\n" {
+	exp_continue
+    }
+    -re "\\\[New Thread \[^\r\n\]+\\\]\r\n" {
+	# Non-stop targets may emit async thread notifications.
+	exp_continue
+    }
+    -re "Reading symbols from /proc/($decimal)/exe[string_to_regexp ...]" {
+	set attached_pid $expect_out(1,string)
+	exp_continue
+    }
+    -re "Reading symbols from (\[^\r\n\]+[string_to_regexp /.nfs]\[^\r\n\]*)[string_to_regexp ...]" {
+	unsupported $gdb_test_name
+	return
+    }
+    -re "Reading symbols from \[^\r\n\]+[string_to_regexp ...]\r\n" {
+	exp_continue
+    }
+    -re -wrap "" {
+	gdb_assert { $attached_pid == $testpid } $gdb_test_name
     }
-}
-
-set test "filename /proc/PID/exe"
-set re_nfs \[^\r\n\]+[string_to_regexp /.nfs]\[^\r\n\]+
-if { [regexp $re_nfs $filename] } {
-    unsupported $test
-} else {
-    gdb_assert { [string equal $filename /proc/${testpid}/exe] } $test
 }
 
 # Restart GDB.
@@ -99,12 +102,18 @@ if { [target_info gdb_protocol] == "extended-remote" } {
 
 verbose -log "APB: warning: No executable has been specified, and target executable $filename_re could not be found\\.  Try using the \"file\" command\\."
 
-gdb_test "attach $testpid" \
-    [multi_line \
-	 "Attaching to process $decimal" \
-	 "warning: No executable has been specified, and target executable $filename_re could not be found\\.  Try using the \"file\" command\\." \
-	 ".*"] \
-    "attach to inferior"
+gdb_test_multiple "attach $testpid" "attach to inferior" {
+    -re "Attaching to process $decimal\r\n" {
+	exp_continue
+    }
+    -re "\\\[New Thread \[^\r\n\]+\\\]\r\n" {
+	# Non-stop targets may emit async thread notifications.
+	exp_continue
+    }
+    -re -wrap "warning: No executable has been specified, and target executable $filename_re could not be found\\.  Try using the \"file\" command\\..*" {
+	pass $gdb_test_name
+    }
+}
 
 # Check GDB hasn't managed to load an executable.
 gdb_test "info inferior" \
-- 
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

[PATCH 10/11] gdb, testsuite: add kfails for step-over-process-exit.exp

[Mohamed Bouhaouel]

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

When running 'gdb.threads/step-over-process-exit.exp' against a
remote target in non-stop mode, GDB fails with a "Remote
communication error" and does not display the expected
"[Inferior ... exited normally]" message.  The test passes in
all-stop mode but fails when target-non-stop is enabled.

Mark the affected assertions as kfail referencing the bug report
gdb/34142 until the underlying issue is resolved.
---
 gdb/testsuite/gdb.threads/step-over-process-exit.exp | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/gdb/testsuite/gdb.threads/step-over-process-exit.exp b/gdb/testsuite/gdb.threads/step-over-process-exit.exp
index 6c98ebe3956..72d270c907a 100644
--- a/gdb/testsuite/gdb.threads/step-over-process-exit.exp
+++ b/gdb/testsuite/gdb.threads/step-over-process-exit.exp
@@ -35,6 +35,11 @@ if { [prepare_for_testing "failed to prepare" $testfile $srcfile {debug pthread}
 # thread, or "other" for the non-main thread.
 
 proc test {which} {
+    if {$which == "other"} {
+	# The failure from the first iteration prevents
+	# the second iteration to run.
+	setup_kfail "gdb/34142" "*-*-*"
+    }
     if {![runto_main]} {
 	return -1
     }
@@ -48,6 +53,7 @@ proc test {which} {
 
     set target_non_stop [is_target_non_stop]
 
+    setup_kfail "gdb/34142" "*-*-*"
     gdb_test_multiple "next" "" {
 	-re -wrap "$::inferior_exited_re normally\\\]" {
 	    pass $gdb_test_name
-- 
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

[PATCH 11/11] gdb, remote: implement always_non_stop_p for remote target

[Mohamed Bouhaouel]

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

Enable remote targets to natively operate in non-stop mode when they
announce QNonStop packet support.  This changes the default setting of
'maint set target-non-stop auto' from 'off' to 'on' for remote targets,
aligning with the Linux native target.
---
 gdb/remote.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/gdb/remote.c b/gdb/remote.c
index 92fe518c6de..ecddb9c587d 100644
--- a/gdb/remote.c
+++ b/gdb/remote.c
@@ -1442,6 +1442,8 @@ class remote_target : public process_stratum_target
 
   void check_binary_download (CORE_ADDR addr);
 
+  bool always_non_stop_p () override;
+
   target_xfer_status remote_write_bytes_aux (const char *header,
 					     CORE_ADDR memaddr,
 					     const gdb_byte *myaddr,
@@ -9877,6 +9879,16 @@ remote_target::check_binary_download (CORE_ADDR addr)
     }
 }
 
+/* Determine whether the remote target natively operates in non-stop mode.
+   Returns true if the target announced QNonStop support for asynchronous
+   execution and stop notifications.  */
+
+bool
+remote_target::always_non_stop_p ()
+{
+  return m_features.packet_support (PACKET_QNonStop) == PACKET_ENABLE;
+}
+
 /* Helper function to resize the payload in order to try to get a good
    alignment.  We try to write an amount of data such that the next write will
    start on an address aligned on REMOTE_ALIGN_WRITES.  */
-- 
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

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

[Bouhaouel, Mohamed]

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

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

[Pedro Alves]

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