Re: [PATCH v3 00/11] Windows non-stop mode

[Pedro Alves <pedro@palves.net>]

Hi Eli,

On 2026-04-30 06:55, Eli Zaretskii wrote:
>> From: Pedro Alves <pedro@palves.net>
>> After the series, the Windows target backend defaults to working in
>> non-stop mode (as in, "maint set target-non-stop"), even if
>> user-visible mode is all-stop ("set non-stop off").  This is the same
>> as the Linux backend.
> 
> I'm not sure this is necessarily a good idea.  Windows is weird in
> this aspect, as you know very well: the system frequently starts
> additional threads for its own purposes, such as handling the Ctrl-C
> and Ctrl-BREAK signals.  Also, many Windows programs have a separate
> UI thread which receives and dispatches the Windows GUI messages.
> Letting those threads run by default when the program stops at a
> breakpoint is not necessarily the best alternative, and perhaps is
> best left to the GDB user in each case (they can do that in
> program-specific .gdbinit, if they need).  Or am I missing something?

What I meant by the above, is that the windows target backend code defaults to
working in non-stop mode, but the user does not see any difference.  When a
breakpoint is hit, GDB still stops all threads.  For the user, it still works the
same, "set non-stop off" is still the default and I don't plan to change that.
The "maint set target-non-stop" setting is just for how the backend communicates
with infrun.  I call this "all-stop on top of non-stop".  Short for
"(user-visible) all-stop on top of (backend working in) non-stop (mode)".
This is how the Linux backend works too.

When the backend works in non-stop mode (the "maint set target-non-stop" setting),
infrun takes responsibility for explicitly stopping all threads when necessary,
instead of the backend implicitly stopping all threads for every reported
internal debug event.  It gives more flexibility to infrun, and is a requirement
for enabling supporting AMD GPU debugging on Windows.  The user doesn't see
anything different.

Pedro Alves