From: Pedro Alves <pedro@palves.net>
To: Mohamed Bouhaouel <mohamed.bouhaouel@intel.com>,
gdb-patches@sourceware.org
Cc: stephan.rohr@intel.com, markus.t.metzger@intel.com
Subject: Re: [PATCH 00/11] Enable non-stop mode by default for remote targets
Date: Fri, 12 Jun 2026 15:20:38 +0100 [thread overview]
Message-ID: <222c9287-4e69-457d-ad91-fd1586f171cf@palves.net> (raw)
In-Reply-To: <20260518183316.127043-1-mohamed.bouhaouel@intel.com>
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
prev parent reply other threads:[~2026-06-12 14:22 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-18 18:32 Mohamed Bouhaouel
2026-05-18 18:32 ` [PATCH 01/11] gdb, record: fix assertion when remote target is set to non-stop Mohamed Bouhaouel
2026-06-10 15:48 ` Andrew Burgess
2026-06-11 15:50 ` Bouhaouel, Mohamed
2026-05-18 18:32 ` [PATCH 02/11] gdb, remote: fix assertion on reconnect to non-stop target Mohamed Bouhaouel
2026-05-18 18:32 ` [PATCH 03/11] gdb, remote: fix async handler " Mohamed Bouhaouel
2026-05-18 18:33 ` [PATCH 04/11] gdb, remote: fix "info program" after " Mohamed Bouhaouel
2026-05-18 18:33 ` [PATCH 05/11] gdb, remote: fix crash when accessing removed events Mohamed Bouhaouel
2026-05-18 18:33 ` [PATCH 06/11] gdb, remote: fix ptid matching for process-wide stop events Mohamed Bouhaouel
2026-05-18 18:33 ` [PATCH 07/11] gdb, dap: fix DAP events if no thread is selected Mohamed Bouhaouel
2026-05-18 18:33 ` [PATCH 08/11] gdb, testsuite: handle async close in monitor-exit-quit.exp Mohamed Bouhaouel
2026-05-18 18:33 ` [PATCH 09/11] gdb, testsuite: update attach-deleted-exec.exp to handle async messages Mohamed Bouhaouel
2026-05-18 18:33 ` [PATCH 10/11] gdb, testsuite: add kfails for step-over-process-exit.exp Mohamed Bouhaouel
2026-05-18 18:33 ` [PATCH 11/11] gdb, remote: implement always_non_stop_p for remote target Mohamed Bouhaouel
2026-06-10 11:44 ` PING 01 - [PATCH 00/11] Enable non-stop mode by default for remote targets Bouhaouel, Mohamed
2026-06-12 14:20 ` Pedro Alves [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=222c9287-4e69-457d-ad91-fd1586f171cf@palves.net \
--to=pedro@palves.net \
--cc=gdb-patches@sourceware.org \
--cc=markus.t.metzger@intel.com \
--cc=mohamed.bouhaouel@intel.com \
--cc=stephan.rohr@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox