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

[Pedro Alves <pedro@palves.net>]

On 2026-04-30 12:14, Eli Zaretskii wrote:
>> Date: Thu, 30 Apr 2026 11:13:55 +0100
>> Cc: gdb-patches@sourceware.org
>> From: 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.
> 
> Thanks.  Now I'm even more confused than before, because not only do
> your explanations contradict the literal meaning of what you say, they
> seem to also contradict what's in the manual.
> 
> You said:
> 
>> 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.
> 
> The "Non-Stop Mode" node in the manual says:
> 
>      In non-stop mode, when a thread stops to report a debugging event,
>   _only_ that thread is stopped; GDB does not stop other threads as well,
>   in contrast to the all-stop mode behavior.

This is a user setting, and it is talking about user-visible stops.  GDB
internally handles stops that the user does not see.  E.g., with
"break foo if cond", the breakpoint hit, gdb evals cond, and if it is
false, gdb re-resumes the program, without the user seeing.

> 
> and
> 
>   'maint set target-non-stop'
>   'maint show target-non-stop'
> 
>        This controls whether GDB targets always operate in non-stop mode
>        even if 'set non-stop' is 'off' (*note Non-Stop Mode::).  The
>        default is 'auto', meaning non-stop mode is enabled if supported by
>        the target.
> 
> So at the very least, there's a very confusing overloading of the
> meaning of "works/operates in non-stop mode", perhaps even double
> overloading.  It seems that you are now saying that the maint setting
> is just an implementation detail, specifying whether infrun or the
> "backend" (whatever that means) 


The target backend, is the target_ops implementation.  gdb/windows-nat.c,
gdb/linux-nat.c, etc.  I thought it would be a familiar term to maintainers.

> stops threads as appropriate for the
> all-stop vs non-stop mode.  It also sounds like the "targets" part in
> "GDB targets always operate in non-stop mode" is very important, as it
> seems that it's specifically meant to tell something important.
> Likewise for the "Windows target backend" in what you wrote above.  To
> a naïve reader such as myself, these all describe the behavior when
> the program hits a breakpoint, because, for me, "target backend" is
> basically a synonym for "inferior" or "debuggee".  But you (and it
> seems the manual as well) use it to specify two very different aspects
> of behavior.

See above.  The target backend, and inferior are definitely different things.

> 
> I think we should clarify the text in the manual, and in particular we
> should not use "operate in non-stop mode" for describing both the
> user-level "set non-stop on" and the maint command.  I would also
> welcome some wording in the description of the maint command to
> clearly indicate that this setting is of no interest to users
> whatsoever, only to GDB developers who work on this mode.  Explaining
> "backend" (not currently described anywhere in the manual AFAICT)
> would also be welcome, as it seems to be relevant for this particular
> issue, and could be used in the manual to clarify this.

OK, I can take a look at this.

> My current, somewhat confused, understanding of the effects of this
> changeset on the Windows native debugging is that users will now be
> able to specify "set non-stop on" without explicit need to say "maint
> set target-non-stop on" before it, because the latter will now be the
> default.  However, the default user-level run mode will still be
> all-stop mode.  Is that correct?
> 


Even with all patches applied except
 '[PATH v3 10/11] Windows gdb: Always non-stop (default to "maint set target-non-stop on")'
you will still be able to use "set non-stop on".

#A - "set non-stop on":

To support "set non-stop on", the target_ops backend implementation (in this case gdb/windows-nat.c), must also support working in non-stop mode.  This means, being able to report stop events to infrun without stopping every thread implicitly.  When you do "set non-stop on", gdb checks if the target backend supports it, with a target_supports_non_stop() call.  You get that with this series, even if patch 10/11 is not merged.

#B - "set non-stop off" (aka all-stop, the default)

  #1 - If the target backend does NOT advertise that it wants to ALWAYS work in non-stop mode, then with "set non-stop off" (the default), then when the inferior hits a breakpoint, finishes a step, etc., the backend stops all threads, and reports the stop to infrun.  If infrun decides the stop is not supposed to be seen by the user, infrun re-resumes all threads again.  All threads stop and are re-resumed for every debug event even if it's an internal event that does not cause a user-visible stop.  This is hidden from the user, though.

  #2 - If the target backend DOES advertise that it wants to ALWAYS work in non-stop mode, then with "set non-stop off" (the default), when the inferior hits a breakpoint, finishes a step, etc., the backend does NOT stop all other threads, it reports the stop to infrun just for that thread that got the event.  infrun then does its business, and if it realizes the stop should be reported to the user, infrun explicitly stops all threads before presenting the stop to the user.  This is more efficient in some scenarios.  (For AMD GPU debugging, it's a requirement.  And for remote debugging, it also enables gdb talking to the remote side while the remote inferior is running.  Etc.)


Patch 10/11 makes the windows target (gdb/windows-nat.c) work like #2 above (for "set non-stop off").  This is what that sentence in the cover letter means.

Thanks,
Pedro Alves