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

[Eli Zaretskii <eliz@gnu.org>]

> 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.

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) 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.

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.

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?