Fw: [PATCH] Improve attach on Windows

Fw: [PATCH] Improve attach on Windows

[Hannes Domani]

Now forwarded to gdb-patches as well.


 ----- Weitergeleitete Nachricht -----

Von: Hannes Domani <ssbssa@yahoo.de>
An: Pedro Alves <pedro@palves.net>
Gesendet: Sonntag, 15. Juni 2025 um 17:08:45 MESZ
Betreff: Re: [PATCH] Improve attach on Windows


Am Mittwoch, 11. Juni 2025 um 23:05:23 MESZ hat Pedro Alves <pedro@palves.net> Folgendes geschrieben:

> Unlike most targets, on Windows, when you attach, GDB doesn't print
> the current stack frame.  Vis:
>
> On GNU/Linux:
>
> attach 3340347
> Attaching to program: /home/pedro/gdb/build/gdb/testsuite/outputs/gdb.base/attach/attach, process 3340347
> Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...
> Reading symbols from /usr/lib/debug/.build-id/d5/197096f709801829b118af1b7cf6631efa2dcd.debug...
> Reading symbols from /lib64/ld-linux-x86-64.so.2...
> Reading symbols from /usr/lib/debug/.build-id/9c/b53985768bb99f138f48655f7b8bf7e420d13d.debug...
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> 0x00005b3bf29be174 in main () at /home/pedro/gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/attach.c:19
> 19        while (! should_exit)
> (gdb) PASS: gdb.base/attach.exp: do_attach_tests: attach1, after setting file
>
> On Cygwin:
>
> (gdb) attach 6692
> Attaching to program: /home/alves/gdb/build-cygwin-testsuite/outputs/gdb.base/attach/attach, process 6692
> [New Thread 6692.0x2e60]
> [New Thread 6692.0x2e9c]
> [New Thread 6692.0xd6c]
> [New Thread 6692.0x137c]
> [New Thread 6692.0x1270]
> (gdb) FAIL: gdb.base/attach.exp: do_attach_tests: attach1, after setting file
>
> On Linux, GDB prints the frame because after the target_attach, GDB
> goes back to the event loop, to wait for an initial stop event.  The
> stop event arrives, and we process it, which sets the stop_print_frame
> global, and then we get to normal_stop, which prints the frame iff
> stop_print_frame is set, which it is.
>
> Windows OTOH, is a target_attach_no_wait target, so after
> target_attach, there is no going back to event loop.  In
> infcmd.c:attach_command, we go straight to attach_post_wait which
> takes us to normal_stop.  But this time, nothing set
> stop_print_frame to true, so no frame is printed.  Actually, if the
> global happened to be true due to an earlier event from debugging a
> previous inferior, then we will print the frame.
>
> This patch makes GDB's behavior consistent, by making sure the globals
> normal_stop looks at are in a good state in the target_attach_no_wait
> path.
>
> With that alone, GDB now prints the frame:
>
> (gdb) attach 2915
> Attaching to program: /usr/bin/sleep.exe, process 2832
> [New Thread 2832.0x2a68]
> [New Thread 2832.0xb1c]
> [New Thread 2832.0x8ac]
> [Switching to Thread 2832.0x8ac]
> 0x00007ffec51d4a71 in ntdll!DbgBreakPoint () from C:/Windows/SYSTEM32/ntdll.dll
>
> This is still not ideal, IMHO, as the current thread is the thread
> that Windows injects to attach:
>
> (gdb) info threads
>   Id  Target Id                  Frame
>   1    Thread 2832.0x2100 "sleep" 0x00007ffec51d18d7 in ntdll!ZwWaitForMultipleObjects () from C:/Windows/SYSTEM32/ntdll.dll
>   2    Thread 2832.0x2a68 "sig"  0x00007ffec51d0e47 in ntdll!ZwReadFile () from C:/Windows/SYSTEM32/ntdll.dll
>   3    Thread 2832.0xb1c          0x00007ffec51d49d7 in ntdll!ZwWaitForWorkViaWorkerFactory () from C:/Windows/SYSTEM32/ntdll.dll
> * 4    Thread 2832.0x8ac          0x00007ffec51d4a71 in ntdll!DbgBreakPoint () from C:/Windows/SYSTEM32/ntdll.dll
>
> Automatically switching to main thread is IMHO more useful.  That
> results in very similar output than what we see on Linux:
>
> attach 5164
> Attaching to program: /home/alves/gdb/build-cygwin-testsuite/outputs/gdb.base/attach/attach, process 5164
> [New Thread 5164.0x87c]
> [New Thread 5164.0x28f0]
> [New Thread 5164.0x376c]
> [New Thread 5164.0x2db4]
> [New Thread 5164.0xce4]
> main () at /home/alves/gdb/src/gdb/testsuite/gdb.base/attach.c:19
> 19        while (! should_exit)
> (gdb)

I wonder if we should do something similar when Ctrl-C is hit.


Regards
Hannes

Re: [PATCH] Improve attach on Windows

[Pedro Alves]

Hi Hannes,

[Guess the list was dropped by mistake, adding it back.]

On 2025-06-15 16:08, Hannes Domani wrote:
>> Automatically switching to main thread is IMHO more useful.  That
>> results in very similar output than what we see on Linux:
>>
>> attach 5164
>> Attaching to program: /home/alves/gdb/build-cygwin-testsuite/outputs/gdb.base/attach/attach, process 5164
>> [New Thread 5164.0x87c]
>> [New Thread 5164.0x28f0]
>> [New Thread 5164.0x376c]
>> [New Thread 5164.0x2db4]
>> [New Thread 5164.0xce4]
>> main () at /home/alves/gdb/src/gdb/testsuite/gdb.base/attach.c:19
>> 19        while (! should_exit)
>> (gdb)
> 
> I wonder if we should do something similar when Ctrl-C is hit.
> 

That could be done, I guess.  I can think of one downside, but I'm not sure
it's strong enough.  If you're debugging a program that has a Ctrl-C handler installed,
and you decide to pass the exception to the program, after GDB intercepted it, you can do
it immediately with "signal SIGINT", or "queue-signal SIGINT; c".  But if GDB automatically
changes threads, then you have to remember to switch to the thread that got the exception,
before issuing the "signal" command.  Maybe that could be sorted out with a warning.  But
then it might be annoying to see the warning all the time.

BTW, in the users/palves/windows-non-stop-v2-plus branch, you'll find some extra patches, and this one:

 commit 95bafb7217bac2d51f5b6a59d34d79bcbaa1eddc
 Author:     Pedro Alves <pedro@palves.net>
 AuthorDate: Fri May 5 15:51:31 2023 +0100
 Commit:     Pedro Alves <pedro@palves.net>
 CommitDate: Mon Jun 9 18:49:19 2025 +0100

    Windows all-stop, interrupt with "stopped" instead of SIGTRAP

... is sort of related.  It doesn't affect pressing Ctrl-C, but it affects explicit
"interrupt", like:

(gdb) c&
Continuing.
(gdb) [New Thread 11688.0x2ff8]
[Thread 11688.0x2e30 exited with code 0]
[New Thread 11688.0x3040]
interrupt 

(gdb) 
Thread 1 "sleep" stopped.
[Switching to Thread 11688.0x2e94]
0x00007ffd839118d7 in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/Windows/SYSTEM32/ntdll.dll


For Ctrl-C, it might be possible to make GDB see the Ctrl-C before the inferior does, and then stop
the inferior with "stopped" too (i.e., just suspend threads, no exception injected.).  I still have
the Ctrl-C rework series that makes Linux work that way (by making the inferior transparently run on
a separate pseudo tty) that I hope I'll eventually be able to get back to.   Not sure Windows would need
a similar treatment, though, but it might.

Pedro Alves

Re: [PATCH] Improve attach on Windows

[Hannes Domani]

 Am Mittwoch, 25. Juni 2025 um 15:32:00 MESZ hat Pedro Alves <pedro@palves.net> Folgendes geschrieben:

> Hi Hannes,
>
> [Guess the list was dropped by mistake, adding it back.]
>
> On 2025-06-15 16:08, Hannes Domani wrote:
> >> Automatically switching to main thread is IMHO more useful.  That
> >> results in very similar output than what we see on Linux:
> >>
> >> attach 5164
> >> Attaching to program: /home/alves/gdb/build-cygwin-testsuite/outputs/gdb.base/attach/attach, process 5164
> >> [New Thread 5164.0x87c]
> >> [New Thread 5164.0x28f0]
> >> [New Thread 5164.0x376c]
> >> [New Thread 5164.0x2db4]
> >> [New Thread 5164.0xce4]
> >> main () at /home/alves/gdb/src/gdb/testsuite/gdb.base/attach.c:19
> >> 19        while (! should_exit)
> >> (gdb)
> >
> > I wonder if we should do something similar when Ctrl-C is hit.
> >
>
> That could be done, I guess.  I can think of one downside, but I'm not sure
> it's strong enough.  If you're debugging a program that has a Ctrl-C handler installed,
> and you decide to pass the exception to the program, after GDB intercepted it, you can do
> it immediately with "signal SIGINT", or "queue-signal SIGINT; c".  But if GDB automatically
> changes threads, then you have to remember to switch to the thread that got the exception,
> before issuing the "signal" command.  Maybe that could be sorted out with a warning.  But
> then it might be annoying to see the warning all the time.

Why would you have to switch threads before "signal", when the signal
is anyways handled in a new thread?


> BTW, in the users/palves/windows-non-stop-v2-plus branch, you'll find some extra patches, and this one:
>
> commit 95bafb7217bac2d51f5b6a59d34d79bcbaa1eddc
> Author:    Pedro Alves <pedro@palves.net>
> AuthorDate: Fri May 5 15:51:31 2023 +0100
> Commit:    Pedro Alves <pedro@palves.net>
> CommitDate: Mon Jun 9 18:49:19 2025 +0100
>
>     Windows all-stop, interrupt with "stopped" instead of SIGTRAP
>
> ... is sort of related.  It doesn't affect pressing Ctrl-C, but it affects explicit
> "interrupt", like:
>
> (gdb) c&
> Continuing.
> (gdb) [New Thread 11688.0x2ff8]
> [Thread 11688.0x2e30 exited with code 0]
> [New Thread 11688.0x3040]
> interrupt
>
> (gdb)
> Thread 1 "sleep" stopped.
> [Switching to Thread 11688.0x2e94]
> 0x00007ffd839118d7 in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/Windows/SYSTEM32/ntdll.dll
>
>
> For Ctrl-C, it might be possible to make GDB see the Ctrl-C before the inferior does, and then stop
> the inferior with "stopped" too (i.e., just suspend threads, no exception injected.).  I still have
> the Ctrl-C rework series that makes Linux work that way (by making the inferior transparently run on
> a separate pseudo tty) that I hope I'll eventually be able to get back to.  Not sure Windows would need
> a similar treatment, though, but it might.

I'm using your Ctrl-C rework series on Linux for years now, and am
always wondering why it wasn't merged yet.

As for a similar treatment on Windows, I guess this would be possible since
Win10, but only needed if "new-console off" (I always use "new-console on").


Hannes

Re: [PATCH] Improve attach on Windows

[Pedro Alves]

Hi!

On 2025-06-29 18:38, Hannes Domani wrote:
>  Am Mittwoch, 25. Juni 2025 um 15:32:00 MESZ hat Pedro Alves <pedro@palves.net> Folgendes geschrieben:
> 
>> Hi Hannes,
>>
>> [Guess the list was dropped by mistake, adding it back.]
>>
>> On 2025-06-15 16:08, Hannes Domani wrote:
>>>> Automatically switching to main thread is IMHO more useful.  That
>>>> results in very similar output than what we see on Linux:
>>>>
>>>> attach 5164
>>>> Attaching to program: /home/alves/gdb/build-cygwin-testsuite/outputs/gdb.base/attach/attach, process 5164
>>>> [New Thread 5164.0x87c]
>>>> [New Thread 5164.0x28f0]
>>>> [New Thread 5164.0x376c]
>>>> [New Thread 5164.0x2db4]
>>>> [New Thread 5164.0xce4]
>>>> main () at /home/alves/gdb/src/gdb/testsuite/gdb.base/attach.c:19
>>>> 19        while (! should_exit)
>>>> (gdb)
>>>
>>> I wonder if we should do something similar when Ctrl-C is hit.
>>>
>>
>> That could be done, I guess.  I can think of one downside, but I'm not sure
>> it's strong enough.  If you're debugging a program that has a Ctrl-C handler installed,
>> and you decide to pass the exception to the program, after GDB intercepted it, you can do
>> it immediately with "signal SIGINT", or "queue-signal SIGINT; c".  But if GDB automatically
>> changes threads, then you have to remember to switch to the thread that got the exception,
>> before issuing the "signal" command.  Maybe that could be sorted out with a warning.  But
>> then it might be annoying to see the warning all the time.
> 
> Why would you have to switch threads before "signal", when the signal
> is anyways handled in a new thread?

"signal SIG" makes GDB pass "SIG" to the current thread.  On Windows, you can only pass
a signal to a thread if that thread last stopped for that signal.  IOW, on Windows, you
can only decide to pass the signal the thread last received, or to suppress it.

See windows_nat_target::prepare_resume in the non-stop series, or windows_nat_target::resume
in current master, where it reads 

  if (sig != GDB_SIGNAL_0)
    {
      if (windows_process.current_event.dwDebugEventCode
	  != EXCEPTION_DEBUG_EVENT)
	{
	  DEBUG_EXCEPT ("Cannot continue with signal %d here.", sig);
	}
      else if (sig == windows_process.last_sig)
	continue_status = DBG_EXCEPTION_NOT_HANDLED;
      else


So, "signal SIGINT" on a thread that was _not_ the thread that got the CtrlC exception
does NOT pass the signal to any thread at all.  If the thread that _did_ get the signal
is not the selected thread when you issue "signal SIGINT", or, if you didn't
use "queue-signal SIGINT" on the thread that got the original CtrlC, then that thread
is continued as normal, which means its SIGINT is suppressed.


> 
> 
>> BTW, in the users/palves/windows-non-stop-v2-plus branch, you'll find some extra patches, and this one:
>>
>> commit 95bafb7217bac2d51f5b6a59d34d79bcbaa1eddc
>> Author:    Pedro Alves <pedro@palves.net>
>> AuthorDate: Fri May 5 15:51:31 2023 +0100
>> Commit:    Pedro Alves <pedro@palves.net>
>> CommitDate: Mon Jun 9 18:49:19 2025 +0100
>>
>>      Windows all-stop, interrupt with "stopped" instead of SIGTRAP
>>
>> ... is sort of related.  It doesn't affect pressing Ctrl-C, but it affects explicit
>> "interrupt", like:
>>
>> (gdb) c&
>> Continuing.
>> (gdb) [New Thread 11688.0x2ff8]
>> [Thread 11688.0x2e30 exited with code 0]
>> [New Thread 11688.0x3040]
>> interrupt
>>
>> (gdb)
>> Thread 1 "sleep" stopped.
>> [Switching to Thread 11688.0x2e94]
>> 0x00007ffd839118d7 in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/Windows/SYSTEM32/ntdll.dll
>>
>>
>> For Ctrl-C, it might be possible to make GDB see the Ctrl-C before the inferior does, and then stop
>> the inferior with "stopped" too (i.e., just suspend threads, no exception injected.).  I still have
>> the Ctrl-C rework series that makes Linux work that way (by making the inferior transparently run on
>> a separate pseudo tty) that I hope I'll eventually be able to get back to.  Not sure Windows would need
>> a similar treatment, though, but it might.
> 
> I'm using your Ctrl-C rework series on Linux for years now, 

Wow, I never thought anybody would be using that patchset locally, especially as its such an invasive change
design wise.  Did you ever run into any problems with it?

> and am always wondering why it wasn't merged yet.

Simply lack of time -- I keep getting pulled into higher priority tasks.  The last time I posted it there were
a few details raised that I need to address.  And then time flies and before you know it a few years have passed.

> 
> As for a similar treatment on Windows, I guess this would be possible since
> Win10, but only needed if "new-console off" (I always use "new-console on").
> 

Right, like on Linux if "set inferior-tty foo" is used GDB doesn't need to do
do the pseudo tty dance.

I don't recall off hand if on Windows there's a way for the program to suppress
CtrlC exceptions completely such that it isn't possible to interrupt the process
in GDB with Ctrl-C, similar to the way a program can block SIGINT or use sigwait
on Linux, which makes it impossible to interrupt with Ctrl-C.  

If on Windows, pressing Ctrl-C _always_ makes the kernel inject a new thread for
the Ctrl-C exception, then I guess the whole intermediary tty thing (which I guess would be
a hidden console on Windows) wouldn't be absolutely needed.  Though it may still be nice for other
reasons, like having total control of the screen with the TUI.

Pedro Alves

Re: [PATCH] Improve attach on Windows

[Hannes Domani]

 Am Dienstag, 1. Juli 2025 um 00:40:28 MESZ hat Pedro Alves <pedro@palves.net> Folgendes geschrieben:

> Hi!
>
> On 2025-06-29 18:38, Hannes Domani wrote:
> >  Am Mittwoch, 25. Juni 2025 um 15:32:00 MESZ hat Pedro Alves <pedro@palves.net> Folgendes geschrieben:
> >
> >> Hi Hannes,
> >>
> >> [Guess the list was dropped by mistake, adding it back.]
> >>
> >> On 2025-06-15 16:08, Hannes Domani wrote:
> >>>> Automatically switching to main thread is IMHO more useful.  That
> >>>> results in very similar output than what we see on Linux:
> >>>>
> >>>> attach 5164
> >>>> Attaching to program: /home/alves/gdb/build-cygwin-testsuite/outputs/gdb.base/attach/attach, process 5164
> >>>> [New Thread 5164.0x87c]
> >>>> [New Thread 5164.0x28f0]
> >>>> [New Thread 5164.0x376c]
> >>>> [New Thread 5164.0x2db4]
> >>>> [New Thread 5164.0xce4]
> >>>> main () at /home/alves/gdb/src/gdb/testsuite/gdb.base/attach.c:19
> >>>> 19        while (! should_exit)
> >>>> (gdb)
> >>>
> >>> I wonder if we should do something similar when Ctrl-C is hit.
> >>>
> >>
> >> That could be done, I guess.  I can think of one downside, but I'm not sure
> >> it's strong enough.  If you're debugging a program that has a Ctrl-C handler installed,
> >> and you decide to pass the exception to the program, after GDB intercepted it, you can do
> >> it immediately with "signal SIGINT", or "queue-signal SIGINT; c".  But if GDB automatically
> >> changes threads, then you have to remember to switch to the thread that got the exception,
> >> before issuing the "signal" command.  Maybe that could be sorted out with a warning.  But
> >> then it might be annoying to see the warning all the time.
> >
> > Why would you have to switch threads before "signal", when the signal
> > is anyways handled in a new thread?
>
> "signal SIG" makes GDB pass "SIG" to the current thread.  On Windows, you can only pass
> a signal to a thread if that thread last stopped for that signal.  IOW, on Windows, you
> can only decide to pass the signal the thread last received, or to suppress it.
>
> See windows_nat_target::prepare_resume in the non-stop series, or windows_nat_target::resume
> in current master, where it reads
>
>   if (sig != GDB_SIGNAL_0)
>     {
>       if (windows_process.current_event.dwDebugEventCode
>       != EXCEPTION_DEBUG_EVENT)
>     {
>       DEBUG_EXCEPT ("Cannot continue with signal %d here.", sig);
>     }
>       else if (sig == windows_process.last_sig)
>     continue_status = DBG_EXCEPTION_NOT_HANDLED;
>       else
>
>
> So, "signal SIGINT" on a thread that was _not_ the thread that got the CtrlC exception
> does NOT pass the signal to any thread at all.  If the thread that _did_ get the signal
> is not the selected thread when you issue "signal SIGINT", or, if you didn't
> use "queue-signal SIGINT" on the thread that got the original CtrlC, then that thread
> is continued as normal, which means its SIGINT is suppressed.

I didn't know about that limitation, goes to show that I never used the signal command.


> >
> >
> >> BTW, in the users/palves/windows-non-stop-v2-plus branch, you'll find some extra patches, and this one:
> >>
> >> commit 95bafb7217bac2d51f5b6a59d34d79bcbaa1eddc
> >> Author:    Pedro Alves <pedro@palves.net>
> >> AuthorDate: Fri May 5 15:51:31 2023 +0100
> >> Commit:    Pedro Alves <pedro@palves.net>
> >> CommitDate: Mon Jun 9 18:49:19 2025 +0100
> >>
> >>      Windows all-stop, interrupt with "stopped" instead of SIGTRAP
> >>
> >> ... is sort of related.  It doesn't affect pressing Ctrl-C, but it affects explicit
> >> "interrupt", like:
> >>
> >> (gdb) c&
> >> Continuing.
> >> (gdb) [New Thread 11688.0x2ff8]
> >> [Thread 11688.0x2e30 exited with code 0]
> >> [New Thread 11688.0x3040]
> >> interrupt
> >>
> >> (gdb)
> >> Thread 1 "sleep" stopped.
> >> [Switching to Thread 11688.0x2e94]
> >> 0x00007ffd839118d7 in ntdll!ZwWaitForMultipleObjects () from /cygdrive/c/Windows/SYSTEM32/ntdll.dll
> >>
> >>
> >> For Ctrl-C, it might be possible to make GDB see the Ctrl-C before the inferior does, and then stop
> >> the inferior with "stopped" too (i.e., just suspend threads, no exception injected.).  I still have
> >> the Ctrl-C rework series that makes Linux work that way (by making the inferior transparently run on
> >> a separate pseudo tty) that I hope I'll eventually be able to get back to.  Not sure Windows would need
> >> a similar treatment, though, but it might.
> >
> > I'm using your Ctrl-C rework series on Linux for years now,
>
> Wow, I never thought anybody would be using that patchset locally, especially as its such an invasive change
> design wise.  Did you ever run into any problems with it?

Can't think of any issues at the moment.

But the main reason I use it is because the pseudo tty made it possible for
me to forward the inferior output to a dedicated TUI window [1].
(nothing fancy, no handling of terminal escape sequences)


> > and am always wondering why it wasn't merged yet.
>
> Simply lack of time -- I keep getting pulled into higher priority tasks.  The last time I posted it there were
> a few details raised that I need to address.  And then time flies and before you know it a few years have passed.
>
> >
> > As for a similar treatment on Windows, I guess this would be possible since
> > Win10, but only needed if "new-console off" (I always use "new-console on").
> >
>
> Right, like on Linux if "set inferior-tty foo" is used GDB doesn't need to do
> do the pseudo tty dance.
>
> I don't recall off hand if on Windows there's a way for the program to suppress
> CtrlC exceptions completely such that it isn't possible to interrupt the process
> in GDB with Ctrl-C, similar to the way a program can block SIGINT or use sigwait
> on Linux, which makes it impossible to interrupt with Ctrl-C.

See removing ENABLE_PROCESSED_INPUT flag with SetConsoleMode [2].
But as far as I know it's not possible to suppress Ctrl-Break.


> If on Windows, pressing Ctrl-C _always_ makes the kernel inject a new thread for
> the Ctrl-C exception, then I guess the whole intermediary tty thing (which I guess would be
> a hidden console on Windows) wouldn't be absolutely needed.  Though it may still be nice for other
> reasons, like having total control of the screen with the TUI.

Yes, that would theoretically make a similar TUI window possible.


[1] https://github.com/ssbssa/gdb/commit/7407d0214109314e2bb559949a2e8f33e9c001d2
[2] https://learn.microsoft.com/en-us/windows/console/setconsolemode


Hannes

[PATCH v2 00/47] Windows non-stop mode

[Pedro Alves]

After a long while (a year, w00t!), here is another iteration of the
Windows non-stop work.

I've pushed the series to the users/palves/windows-non-stop-v2 branch
on sourceware.org, for your convenience.

Compared to the previous version from a year ago (gasp!), here:

 https://inbox.sourceware.org/gdb-patches/20240507234233.371123-1-pedro@palves.net/

... many issues where fixed, and it should be a lot more stable.  I
think I fixed the problems Tromey found out when he ran the series
against the AdaCore testsuite, particularly around detaching.

The series is bigger, it is now 47 patches instead of 34.

These patches are new:

 + [PATCH v2 01/47] Make default_gdb_exit resilient to failed closes
 + [PATCH v2 02/47] Add test for continuing with some threads running
 + [PATCH v2 03/47] infrun: Remove unnecessary currently_stepping call
 + [PATCH v2 04/47] infrun: Split currently_stepping, fix sw watchpoints issue
 + [PATCH v2 05/47] thread_info::executing+resumed -> thread_info::internal_state
 + [PATCH v2 36/47] linux-nat: Factor out get_detach_signal code to common code
 + [PATCH v2 37/47] Windows GDB: make windows_thread_info be private thread_info data
 + [PATCH v2 38/47] Introduce windows_nat::event_code_to_string
 + [PATCH v2 40/47] Windows gdb: Eliminate invalidate_context
 + [PATCH v2 42/47] gdb_test_multiple: Anchor prompt match if -lbl
 + [PATCH v2 43/47] Windows gdb: extra thread info => show exiting
 + [PATCH v2 44/47] Add gdb.threads/leader-exit-schedlock.exp
 + [PATCH v2 45/47] infrun: with AS+NS, prefer process exit over thread exit
 + [PATCH v2 46/47] Windows gdb: Always non-stop

The last one above (#46) was split from the main non-stop patch so
that AS-on-NS is only activated after the new infrun changes are
merged.

Note that patches above with subject that starts with "infrun" or
"thread_info" are changes to common code.

This patch from the previous version of the series was dropped:

 -  windows_per_inferior::continue_one_thread, unify WoW64/non-WoW64 paths

... as no longer needed, since Hannes's:

  commit b2682eade4db993bc8231007ba94aec4e4728c61
  Author:     Hannes Domani <ssbssa@yahoo.de>
  AuthorDate: Fri Dec 6 14:04:00 2024 +0100

      Reduce WOW64 code duplication

The "Windows gdb: Add non-stop support" patch changed in some
important areas compared to the previous version.  Here's a summary:

 - We can't use DBG_REPLY_LATER with thread/process exit events.  For
   those, we need to use the pre-exiting pending-status mechanism.

 - When a thread that is abruptly killed has a pending DBG_REPLY_LATER
   reply queued in the kernel, we always see that queued event first
   before the thread exit event.

 - The above two points required careful handling of the
   (th->suspended == -1) state in some places.

 - windows-nat.c was in some cases deleting the thread before
   reporting TARGET_WAITKIND_THREAD_EXITED to infrun (when
   target_thread_events was active), resulting in a double free,
   because infrun deletes the thread as well.  OTOH, when
   TARGET_WAITKIND_THREAD_EXITED was reported and windows-nat.c didn't
   delete the thread, nothing was deleting the corresponding
   windows_thread_info object, resulting weird confusion in the
   windows backend, with stale threads still in the backend list.

 - TARGET_WAITKIND_NO_RESUMED is now implemented.

 - The new "Add gdb.threads/leader-exit-schedlock.exp" patch adds a
   test that exercises all the points above.  The pre-existing
   "gdb.base/ending-run.exp" testcase also covers some aspects.

 - Adjusted to new model introduced by the
   "thread_info::executing+resumed -> thread_info::internal_state"
   patch earlier in the series.

 - Adjusted to windows_thread_info being owned by the thread_info
   object.

 - The do_initial_windows_stuff run-to-initial-breakpoint loop now
   handles target_thread_events enabled correctly.

 - Fixes detaching with queued DBG_REPLY_LATER events on the kernel
   side.  The Windows kernel re-raises any exception previously
   intercepted and deferred with DBG_REPLY_LATER in the inferior after
   we detach.  We need to flush those events, otherwise the inferior
   dies immediately after the detach, due to an unhandled exception.

 - The intro text added to windows-nat.c has more paragraphs and
   sections detailing the new things I've learned along the way since
   the last time.

In the NEWS patch, I'm now mentioning scheduler-locking support too.
Previously I only mentioned non-stop.

I've added "Approved-By:" tags from last year's review, to patches
that haven't changed since.  Some of them I could have pushed back
then, but I didn't want to do that until the v2 series was complete,
in case some problems I was addressing in v2 were caused by those
preparatory patches.

The "prerequisite-patch-id" at the bottom is:

 [PATCH] Fix build when RUSAGE_THREAD is not available & add warning
 https://inbox.sourceware.org/gdb-patches/20250517213056.3251858-1-pedro@palves.net/T/#u

Here's the original intro blurb, still accurate:

This series adds non-stop mode support to the Windows native backend,
on Windows 10 and above.  Earlier Windows versions lack the necessary
feature, so those keep working in all-stop mode, only.

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've been testing this on Cygwin native with the GDB testsuite as I've
been developing this.  Running the testsuite on Cygwin is a pain, and
many testcases run into cascading timeouts still, and some even hang
the test run forever until you kill them manually.  I've got another
series of patches to improve such tests and skip others, and that's
what I've been testing with.  I've also tested the series with the
windows-nat backend forced to all-stop mode.

Pedro Alves (47):
  Make default_gdb_exit resilient to failed closes
  Add test for continuing with some threads running
  infrun: Remove unnecessary currently_stepping call
  infrun: Split currently_stepping, fix sw watchpoints issue
  thread_info::executing+resumed -> thread_info::internal_state
  Windows gdb: Dead code in windows_nat_target::do_initial_windows_stuff
  Windows gdb: Eliminate global current_process.dr[8] global
  Windows gdb+gdbserver: New find_thread, replaces
    thread_rec(DONT_INVALIDATE_CONTEXT)
  Windows gdb: handle_output_debug_string return type
  Windows gdb: Eliminate reload_context
  Windows gdb+gdbserver: Eliminate thread_rec(INVALIDATE_CONTEXT) calls
  Windows gdb+gdbserver: Eliminate DONT_SUSPEND
  Windows gdb+gdbserver: Eliminate windows_process_info::thread_rec
  Windows gdb: Simplify windows_nat_target::wait
  Windows gdb+gdbserver: Move suspending thread to when returning event
  Windows gdb: Introduce continue_last_debug_event_main_thread
  Windows gdb: Introduce windows_continue_flags
  Windows gdb: Factor code out of windows_nat_target::windows_continue
  Windows gdb: Pending stop and current_event
  Windows gdb+gdbserver: Elim desired_stop_thread_id / rework
    pending_stops
  Windows gdb+gdbserver: Introduce get_last_debug_event_ptid
  Windows gdb: Can't pass signal to thread other than last stopped
    thread
  Windows gdbserver: Fix scheduler-locking
  Windows gdb: Enable "set scheduler-locking on"
  Windows gdbserver: Eliminate soft-interrupt mechanism
  Windows gdb+gdbserver: Make current_event per-thread state
  Windows gdb+gdbserver: Make last_sig per-thread state
  Windows gdb+gdbserver: Make siginfo_er per-thread state
  Add backpointer from windows_thread_info to windows_process_info
  Windows gdb+gdbserver: Share $_siginfo reading code
  Windows gdb+gdbserver: Eliminate struct pending_stop
  Windows gdb: Change serial_event management
  Windows gdb: cygwin_set_dr => windows_set_dr, etc.
  Windows gdb: Avoid writing debug registers if watchpoint hit pending
  Windows gdb+gdbserver: Check whether DBG_REPLY_LATER is available
  linux-nat: Factor out get_detach_signal code to common code
  Windows GDB: make windows_thread_info be private thread_info data
  Introduce windows_nat::event_code_to_string
  Windows gdb: Add non-stop support
  Windows gdb: Eliminate invalidate_context
  Windows gdb: Watchpoints while running (internal vs external stops)
  gdb_test_multiple: Anchor prompt match if -lbl
  Windows gdb: extra thread info => show exiting
  Add gdb.threads/leader-exit-schedlock.exp
  infrun: with AS+NS, prefer process exit over thread exit
  Windows gdb: Always non-stop (default to "maint set target-non-stop
    on")
  Mention Windows scheduler-locking and non-stop support in NEWS

 gdb/NEWS                                      |    6 +
 gdb/aarch64-tdep.c                            |    2 +-
 gdb/amd-dbgapi-target.c                       |    8 +-
 gdb/breakpoint.c                              |    9 +-
 gdb/bsd-uthread.c                             |    4 +-
 gdb/fork-child.c                              |    4 +-
 gdb/frame.c                                   |    4 +-
 gdb/gcore.c                                   |    4 +-
 gdb/gdbthread.h                               |  150 +-
 gdb/i386-tdep.c                               |    4 +-
 gdb/inf-ptrace.c                              |    2 +-
 gdb/infcall.c                                 |    8 +-
 gdb/infcmd.c                                  |   39 +-
 gdb/inferior.h                                |    4 +-
 gdb/inflow.c                                  |    2 +-
 gdb/infrun.c                                  |  429 ++--
 gdb/infrun.h                                  |   13 +-
 gdb/linux-fork.c                              |    9 +-
 gdb/linux-nat.c                               |   44 +-
 gdb/linux-thread-db.c                         |    4 +-
 gdb/mi/mi-cmd-var.c                           |    4 +-
 gdb/mi/mi-interp.c                            |    2 +-
 gdb/mi/mi-main.c                              |    8 +-
 gdb/nat/windows-nat.c                         |  176 +-
 gdb/nat/windows-nat.h                         |  223 +-
 gdb/process-stratum-target.c                  |    6 +-
 gdb/python/py-infthread.c                     |    6 +-
 gdb/record-btrace.c                           |   20 +-
 gdb/record-full.c                             |    6 +-
 gdb/regcache.c                                |    2 +-
 gdb/remote.c                                  |   76 +-
 gdb/sol-thread.c                              |    4 +-
 gdb/target.c                                  |   15 +-
 .../gdb.threads/continue-some-running.c       |   76 +
 .../gdb.threads/continue-some-running.exp     |   52 +
 .../gdb.threads/leader-exit-schedlock.c       |   56 +
 .../gdb.threads/leader-exit-schedlock.exp     |  215 ++
 .../gdb.threads/step-over-process-exit.c      |   49 +
 .../gdb.threads/step-over-process-exit.exp    |   66 +
 .../sw-watchpoint-step-over-bp-with-threads.c |   64 +
 ...w-watchpoint-step-over-bp-with-threads.exp |   91 +
 gdb/testsuite/lib/gdb.exp                     |    8 +-
 gdb/thread-iter.h                             |    2 +-
 gdb/thread.c                                  |  299 ++-
 gdb/top.c                                     |    2 +-
 gdb/windows-nat.c                             | 2033 +++++++++++++----
 gdbserver/win32-low.cc                        |  450 ++--
 gdbserver/win32-low.h                         |   19 +-
 48 files changed, 3369 insertions(+), 1410 deletions(-)
 create mode 100644 gdb/testsuite/gdb.threads/continue-some-running.c
 create mode 100644 gdb/testsuite/gdb.threads/continue-some-running.exp
 create mode 100644 gdb/testsuite/gdb.threads/leader-exit-schedlock.c
 create mode 100644 gdb/testsuite/gdb.threads/leader-exit-schedlock.exp
 create mode 100644 gdb/testsuite/gdb.threads/step-over-process-exit.c
 create mode 100644 gdb/testsuite/gdb.threads/step-over-process-exit.exp
 create mode 100644 gdb/testsuite/gdb.threads/sw-watchpoint-step-over-bp-with-threads.c
 create mode 100644 gdb/testsuite/gdb.threads/sw-watchpoint-step-over-bp-with-threads.exp


base-commit: e1ec485cfa29f9c45370b9d0c12480ebb0a0be06
prerequisite-patch-id: 474281ed1de7dcad710a9f1415fe4866fe3e36cb
-- 
2.49.0

Re: [PATCH v2 00/47] Windows non-stop mode

[Tom Tromey]

>>>>> "Pedro" == Pedro Alves <pedro@palves.net> writes:

Pedro> I've pushed the series to the users/palves/windows-non-stop-v2 branch
Pedro> on sourceware.org, for your convenience.

I merged this into the local tree and ran the internal AdaCore test
suite on Windows 2016.

There were three "failures".

One of them is actually an improvement, where the test works around a
current issue.

One of them seems to be a problem with the test.  This test "attach"es
to a running process without a "file", and the test doesn't seem to
match the new output:

    (gdb) attach 1228
    Attaching to process 1228
    [Switching to Thread 1228.0x580]
    0x00007ffe3c756714 in ntdll!ZwDelayExecution ()
       from C:\Windows\SYSTEM32\ntdll.dll

I'm not quite as sure about the last one.  This test sets a couple of
breakpoints that have 'commands', where the commands delete the
breakpoint, like:

[ break main.adb:4 then ... ]
        "silent",
        'printf "Breakpoint hit #1.\\n"',
        "clear main.adb:4",
        "continue",
        "end",

When running the expected output is seen but gdb says:

    (gdb) run
    Starting program: C:\[...]
    Breakpoint hit #1.
    Breakpoint hit #2.
    No unwaited-for children left.

It's that last line that causes the problem.  The test expects an "exit
notification", which is kind of complicated in this test suite, but I
think for native testing boils down to a message like "[Inferior
... exited ...]".

I see this "unwaited-for" text in infrun.c.  But I wonder if this is
really intended.

thanks,
Tom

[PATCH] Improve attach on Windows (was: Re: [PATCH v2 00/47] Windows non-stop mode)

[Pedro Alves]

Hi!

On 2025-06-05 18:57, Tom Tromey wrote:
>>>>>> "Pedro" == Pedro Alves <pedro@palves.net> writes:
> 
> Pedro> I've pushed the series to the users/palves/windows-non-stop-v2 branch
> Pedro> on sourceware.org, for your convenience.
> 
> I merged this into the local tree and ran the internal AdaCore test
> suite on Windows 2016.

Thank you very much for doing this.  Much appreciated.

> 
> There were three "failures".
> 
> One of them is actually an improvement, where the test works around a
> current issue.
> 

One step forward, two steps back, I guess.

Tackling this incrementally.  I've looked at the first one:

> One of them seems to be a problem with the test.  This test "attach"es
> to a running process without a "file", and the test doesn't seem to
> match the new output:
> 
>     (gdb) attach 1228
>     Attaching to process 1228
>     [Switching to Thread 1228.0x580]
>     0x00007ffe3c756714 in ntdll!ZwDelayExecution ()
>        from C:\Windows\SYSTEM32\ntdll.dll
> 

I guess your test wasn't expecting that the current frame is printed?

See the patch below, on top of current master.  You are now seeing the current
frame being printed, unlike what I claim in the commit log of the patch below,
because with target-non-stop on, the Windows backend is a target_wait_no_wait==false
target, like Linux.

But even with the non-stop series, with "maint set target-non-stop off",
(or with Windows older than Windows 10,) then target_wait_no_wait==true, and
GDB doesn't print the frame.

IMO, this is just a preexisting bug that the non-stop series happens to hide.

Let me know what you think of the patch.

And yes, the fact that run control communicates with normal_stop via
globals is ugly and fragile to say the least.

From 0cb83571c91ba42b3de519b034509092a526dc65 Mon Sep 17 00:00:00 2001
From: Pedro Alves <pedro@palves.net>
Date: Wed, 11 Jun 2025 22:05:23 +0100
Subject: [PATCH] Improve attach on Windows

Unlike most targets, on Windows, when you attach, GDB doesn't print
the current stack frame.  Vis:

On GNU/Linux:

 attach 3340347
 Attaching to program: /home/pedro/gdb/build/gdb/testsuite/outputs/gdb.base/attach/attach, process 3340347
 Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...
 Reading symbols from /usr/lib/debug/.build-id/d5/197096f709801829b118af1b7cf6631efa2dcd.debug...
 Reading symbols from /lib64/ld-linux-x86-64.so.2...
 Reading symbols from /usr/lib/debug/.build-id/9c/b53985768bb99f138f48655f7b8bf7e420d13d.debug...
 [Thread debugging using libthread_db enabled]
 Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
 0x00005b3bf29be174 in main () at /home/pedro/gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/attach.c:19
 19        while (! should_exit)
 (gdb) PASS: gdb.base/attach.exp: do_attach_tests: attach1, after setting file

On Cygwin:

 (gdb) attach 6692
 Attaching to program: /home/alves/gdb/build-cygwin-testsuite/outputs/gdb.base/attach/attach, process 6692
 [New Thread 6692.0x2e60]
 [New Thread 6692.0x2e9c]
 [New Thread 6692.0xd6c]
 [New Thread 6692.0x137c]
 [New Thread 6692.0x1270]
 (gdb) FAIL: gdb.base/attach.exp: do_attach_tests: attach1, after setting file

On Linux, GDB prints the frame because after the target_attach, GDB
goes back to the event loop, to wait for an initial stop event.  The
stop event arrives, and we process it, which sets the stop_print_frame
global, and then we get to normal_stop, which prints the frame iff
stop_print_frame is set, which it is.

Windows OTOH, is a target_attach_no_wait target, so after
target_attach, there is no going back to event loop.  In
infcmd.c:attach_command, we go straight to attach_post_wait which
takes us to normal_stop.  But this time, nothing set
stop_print_frame to true, so no frame is printed.  Actually, if the
global happened to be true due to an earlier event from debugging a
previous inferior, then we will print the frame.

This patch makes GDB's behavior consistent, by making sure the globals
normal_stop looks at are in a good state in the target_attach_no_wait
path.

With that alone, GDB now prints the frame:

 (gdb) attach 2915
 Attaching to program: /usr/bin/sleep.exe, process 2832
 [New Thread 2832.0x2a68]
 [New Thread 2832.0xb1c]
 [New Thread 2832.0x8ac]
 [Switching to Thread 2832.0x8ac]
 0x00007ffec51d4a71 in ntdll!DbgBreakPoint () from C:/Windows/SYSTEM32/ntdll.dll

This is still not ideal, IMHO, as the current thread is the thread
that Windows injects to attach:

 (gdb) info threads
   Id   Target Id                  Frame
   1    Thread 2832.0x2100 "sleep" 0x00007ffec51d18d7 in ntdll!ZwWaitForMultipleObjects () from C:/Windows/SYSTEM32/ntdll.dll
   2    Thread 2832.0x2a68 "sig"   0x00007ffec51d0e47 in ntdll!ZwReadFile () from C:/Windows/SYSTEM32/ntdll.dll
   3    Thread 2832.0xb1c          0x00007ffec51d49d7 in ntdll!ZwWaitForWorkViaWorkerFactory () from C:/Windows/SYSTEM32/ntdll.dll
 * 4    Thread 2832.0x8ac          0x00007ffec51d4a71 in ntdll!DbgBreakPoint () from C:/Windows/SYSTEM32/ntdll.dll

Automatically switching to main thread is IMHO more useful.  That
results in very similar output than what we see on Linux:

 attach 5164
 Attaching to program: /home/alves/gdb/build-cygwin-testsuite/outputs/gdb.base/attach/attach, process 5164
 [New Thread 5164.0x87c]
 [New Thread 5164.0x28f0]
 [New Thread 5164.0x376c]
 [New Thread 5164.0x2db4]
 [New Thread 5164.0xce4]
 main () at /home/alves/gdb/src/gdb/testsuite/gdb.base/attach.c:19
 19        while (! should_exit)
 (gdb)

If we do this, then we can simplify gdb.base/attach.exp a bit by
removing a couple Cygwin special cases.

The patch does all that, which results in the following
gdb.base/attach.exp progressions:

 -FAIL: gdb.base/attach.exp: do_attach_tests: attach1, after setting file
 -FAIL: gdb.base/attach.exp: do_attach_tests: attach2, with no file
 -FAIL: gdb.base/attach.exp: do_attach_tests: load file manually, after attach2 (re-read) (got interactive prompt)
 -FAIL: gdb.base/attach.exp: do_attach_tests: attach when process' a.out not in cwd
 -FAIL: gdb.base/attach.exp: do_attach_failure_tests: first attach
 +PASS: gdb.base/attach.exp: do_attach_tests: attach1, after setting file
 +PASS: gdb.base/attach.exp: do_attach_tests: attach2, with no file
 +PASS: gdb.base/attach.exp: do_attach_tests: attach when process' a.out not in cwd
 +PASS: gdb.base/attach.exp: do_attach_failure_tests: first attach

Change-Id: I359bdb25660c9a4d5d873e8771cfd1cd2a54c97b
---
 gdb/infcmd.c                      |  5 ++++-
 gdb/infrun.c                      | 13 +++++++++++++
 gdb/infrun.h                      |  3 +++
 gdb/testsuite/gdb.base/attach.exp | 26 ++++++--------------------
 gdb/windows-nat.c                 |  7 +++++++
 5 files changed, 33 insertions(+), 21 deletions(-)

diff --git a/gdb/infcmd.c b/gdb/infcmd.c
index e9b58ce5521..cbf2373193c 100644
--- a/gdb/infcmd.c
+++ b/gdb/infcmd.c
@@ -2722,7 +2722,10 @@ attach_command (const char *args, int from_tty)
       return;
     }
   else
-    attach_post_wait (from_tty, mode);
+    {
+      set_normal_stop_state_just_attached ();
+      attach_post_wait (from_tty, mode);
+    }
 
   disable_commit_resumed.reset_and_commit ();
 }
diff --git a/gdb/infrun.c b/gdb/infrun.c
index 2e02642c52a..41ab3342ee3 100644
--- a/gdb/infrun.c
+++ b/gdb/infrun.c
@@ -407,6 +407,19 @@ static process_stratum_target *target_last_proc_target;
 static ptid_t target_last_wait_ptid;
 static struct target_waitstatus target_last_waitstatus;
 
+/* See infrun.h.  */
+
+void
+set_normal_stop_state_just_attached ()
+{
+  stop_print_frame = true;
+  stopped_by_random_signal = 0;
+
+  target_waitstatus status;
+  status.set_ignore ();
+  set_last_target_status (nullptr, minus_one_ptid, status);
+}
+
 void init_thread_stepping_state (struct thread_info *tss);
 
 static const char follow_fork_mode_child[] = "child";
diff --git a/gdb/infrun.h b/gdb/infrun.h
index b9b64aca45a..b707314fba6 100644
--- a/gdb/infrun.h
+++ b/gdb/infrun.h
@@ -418,5 +418,8 @@ struct scoped_enable_commit_resumed
   bool m_prev_enable_commit_resumed;
 };
 
+/* Set up state for normal_stop after we just attached, on
+   target_attach_no_wait targets.  */
+extern void set_normal_stop_state_just_attached ();
 
 #endif /* GDB_INFRUN_H */
diff --git a/gdb/testsuite/gdb.base/attach.exp b/gdb/testsuite/gdb.base/attach.exp
index 0d1550a0541..484fa776ae4 100644
--- a/gdb/testsuite/gdb.base/attach.exp
+++ b/gdb/testsuite/gdb.base/attach.exp
@@ -159,16 +159,9 @@ proc_with_prefix do_attach_failure_tests {} {
     
     # Verify that we can't double attach to the process.
 
-    set test "first attach"
-    gdb_test_multiple "attach $testpid" "$test" {
-	-re "Attaching to program.*`?$escapedbinfile'?, process $testpid.*main.*at .*$srcfile:.*$gdb_prompt $" {
-	    pass "$test"
-	}
-	-re "Attaching to program.*`?$escapedbinfile\.exe'?, process $testpid.*\[Switching to thread $testpid\..*\].*$gdb_prompt $" {
-	    # Response expected on Cygwin.
-	    pass "$test"
-	}
-    }
+    gdb_test "attach $testpid" \
+	"Attaching to program.*`?${escapedbinfile}(\.exe)?'?, process $testpid.*main.*at .*$srcfile:.*" \
+	"first attach"
 
     gdb_test "add-inferior" "Added inferior 2.*" "add empty inferior 2"
     gdb_test "inferior 2" "Switching to inferior 2.*" "switch to inferior 2"
@@ -252,16 +245,9 @@ proc_with_prefix do_attach_tests {} {
 	}
     }
 
-    set test "attach1, after setting file"
-    gdb_test_multiple "attach $testpid" "$test" {
-	-re "Attaching to program.*`?$escapedbinfile'?, process $testpid.*main.*at .*$srcfile:.*$gdb_prompt $" {
-	    pass "$test"
-	}
-	-re "Attaching to program.*`?$escapedbinfile\.exe'?, process $testpid.*\[Switching to thread $testpid\..*\].*$gdb_prompt $" {
-	    # Response expected on Cygwin
-	    pass "$test"
-	}
-    }
+    gdb_test "attach $testpid" \
+	"Attaching to program.*`?${escapedbinfile}(\.exe)?'?, process $testpid.*main.*at .*$srcfile:.*" \
+	"attach1, after setting file"
 
     # Verify that we can "see" the variable "should_exit" in the
     # program, and that it is zero.
diff --git a/gdb/windows-nat.c b/gdb/windows-nat.c
index 939c5813aa7..0477731d40c 100644
--- a/gdb/windows-nat.c
+++ b/gdb/windows-nat.c
@@ -1980,6 +1980,13 @@ windows_nat_target::attach (const char *args, int from_tty)
 #endif
 
   do_initial_windows_stuff (pid, 1);
+
+  /* The thread that reports the initial breakpoint, and thus ends up
+     as the selected thread when we get here, was injected into the
+     inferior by DebugActiveProcess.  Switch to the main thread, which
+     is normally more useful to the user than the injected thread.  */
+  switch_to_thread (first_thread_of_inferior (current_inferior ()));
+
   target_terminal::ours ();
 }
 

base-commit: eb6c9310ee4d6cbde509d251fafb54ae45f5a5bf
-- 
2.49.0

Re: [PATCH] Improve attach on Windows

[Pedro Alves]

Hi!

I'm looking at the windows non-stop series again, trying to figure out where we were.

There was one problem exposed by the AdaCore testsuite that I wasn't able to reproduce locally, so I don't know what to do about it.

More below.

I'll look at the rest of the series, rebase, and see what can be merged already.

On 2025-06-11 23:06, Pedro Alves wrote:

> On 2025-06-05 18:57, Tom Tromey wrote:
>>>>>>> "Pedro" == Pedro Alves <pedro@palves.net> writes:
>>
>> Pedro> I've pushed the series to the users/palves/windows-non-stop-v2 branch
>> Pedro> on sourceware.org, for your convenience.
>>
>> I merged this into the local tree and ran the internal AdaCore test
>> suite on Windows 2016.
> 
> Thank you very much for doing this.  Much appreciated.
> 
>>
>> There were three "failures".
>>
>> One of them is actually an improvement, where the test works around a
>> current issue.
>>
> 
> One step forward, two steps back, I guess.
> 
> Tackling this incrementally.  I've looked at the first one:
> 
>> One of them seems to be a problem with the test.  This test "attach"es
>> to a running process without a "file", and the test doesn't seem to
>> match the new output:
>>
>>     (gdb) attach 1228
>>     Attaching to process 1228
>>     [Switching to Thread 1228.0x580]
>>     0x00007ffe3c756714 in ntdll!ZwDelayExecution ()
>>        from C:\Windows\SYSTEM32\ntdll.dll
>>
> 
> I guess your test wasn't expecting that the current frame is printed?
> 
> See the patch below, on top of current master.  You are now seeing the current
> frame being printed, unlike what I claim in the commit log of the patch below,
> because with target-non-stop on, the Windows backend is a target_wait_no_wait==false
> target, like Linux.
> 
> But even with the non-stop series, with "maint set target-non-stop off",
> (or with Windows older than Windows 10,) then target_wait_no_wait==true, and
> GDB doesn't print the frame.
> 
> IMO, this is just a preexisting bug that the non-stop series happens to hide.
> 
> Let me know what you think of the patch.
> 
> And yes, the fact that run control communicates with normal_stop via
> globals is ugly and fragile to say the least.
> 
> From 0cb83571c91ba42b3de519b034509092a526dc65 Mon Sep 17 00:00:00 2001
> From: Pedro Alves <pedro@palves.net>
> Date: Wed, 11 Jun 2025 22:05:23 +0100
> Subject: [PATCH] Improve attach on Windows

I think this one is a clear and easy improvement.
I've retested it, and I see the same progression in gdb.base/attach.exp, so I've now pushed it.

Thanks,
Pedro Alves

> 
> Unlike most targets, on Windows, when you attach, GDB doesn't print
> the current stack frame.  Vis:
> 
> On GNU/Linux:
> 
>  attach 3340347
>  Attaching to program: /home/pedro/gdb/build/gdb/testsuite/outputs/gdb.base/attach/attach, process 3340347
>  Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...
>  Reading symbols from /usr/lib/debug/.build-id/d5/197096f709801829b118af1b7cf6631efa2dcd.debug...
>  Reading symbols from /lib64/ld-linux-x86-64.so.2...
>  Reading symbols from /usr/lib/debug/.build-id/9c/b53985768bb99f138f48655f7b8bf7e420d13d.debug...
>  [Thread debugging using libthread_db enabled]
>  Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
>  0x00005b3bf29be174 in main () at /home/pedro/gdb/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.base/attach.c:19
>  19        while (! should_exit)
>  (gdb) PASS: gdb.base/attach.exp: do_attach_tests: attach1, after setting file
> 
> On Cygwin:
> 
>  (gdb) attach 6692
>  Attaching to program: /home/alves/gdb/build-cygwin-testsuite/outputs/gdb.base/attach/attach, process 6692
>  [New Thread 6692.0x2e60]
>  [New Thread 6692.0x2e9c]
>  [New Thread 6692.0xd6c]
>  [New Thread 6692.0x137c]
>  [New Thread 6692.0x1270]
>  (gdb) FAIL: gdb.base/attach.exp: do_attach_tests: attach1, after setting file
> 
> On Linux, GDB prints the frame because after the target_attach, GDB
> goes back to the event loop, to wait for an initial stop event.  The
> stop event arrives, and we process it, which sets the stop_print_frame
> global, and then we get to normal_stop, which prints the frame iff
> stop_print_frame is set, which it is.
> 
> Windows OTOH, is a target_attach_no_wait target, so after
> target_attach, there is no going back to event loop.  In
> infcmd.c:attach_command, we go straight to attach_post_wait which
> takes us to normal_stop.  But this time, nothing set
> stop_print_frame to true, so no frame is printed.  Actually, if the
> global happened to be true due to an earlier event from debugging a
> previous inferior, then we will print the frame.
> 
> This patch makes GDB's behavior consistent, by making sure the globals
> normal_stop looks at are in a good state in the target_attach_no_wait
> path.
> 
> With that alone, GDB now prints the frame:
> 
>  (gdb) attach 2915
>  Attaching to program: /usr/bin/sleep.exe, process 2832
>  [New Thread 2832.0x2a68]
>  [New Thread 2832.0xb1c]
>  [New Thread 2832.0x8ac]
>  [Switching to Thread 2832.0x8ac]
>  0x00007ffec51d4a71 in ntdll!DbgBreakPoint () from C:/Windows/SYSTEM32/ntdll.dll
> 
> This is still not ideal, IMHO, as the current thread is the thread
> that Windows injects to attach:
> 
>  (gdb) info threads
>    Id   Target Id                  Frame
>    1    Thread 2832.0x2100 "sleep" 0x00007ffec51d18d7 in ntdll!ZwWaitForMultipleObjects () from C:/Windows/SYSTEM32/ntdll.dll
>    2    Thread 2832.0x2a68 "sig"   0x00007ffec51d0e47 in ntdll!ZwReadFile () from C:/Windows/SYSTEM32/ntdll.dll
>    3    Thread 2832.0xb1c          0x00007ffec51d49d7 in ntdll!ZwWaitForWorkViaWorkerFactory () from C:/Windows/SYSTEM32/ntdll.dll
>  * 4    Thread 2832.0x8ac          0x00007ffec51d4a71 in ntdll!DbgBreakPoint () from C:/Windows/SYSTEM32/ntdll.dll
> 
> Automatically switching to main thread is IMHO more useful.  That
> results in very similar output than what we see on Linux:
> 
>  attach 5164
>  Attaching to program: /home/alves/gdb/build-cygwin-testsuite/outputs/gdb.base/attach/attach, process 5164
>  [New Thread 5164.0x87c]
>  [New Thread 5164.0x28f0]
>  [New Thread 5164.0x376c]
>  [New Thread 5164.0x2db4]
>  [New Thread 5164.0xce4]
>  main () at /home/alves/gdb/src/gdb/testsuite/gdb.base/attach.c:19
>  19        while (! should_exit)
>  (gdb)
> 
> If we do this, then we can simplify gdb.base/attach.exp a bit by
> removing a couple Cygwin special cases.
> 
> The patch does all that, which results in the following
> gdb.base/attach.exp progressions:
> 
>  -FAIL: gdb.base/attach.exp: do_attach_tests: attach1, after setting file
>  -FAIL: gdb.base/attach.exp: do_attach_tests: attach2, with no file
>  -FAIL: gdb.base/attach.exp: do_attach_tests: load file manually, after attach2 (re-read) (got interactive prompt)
>  -FAIL: gdb.base/attach.exp: do_attach_tests: attach when process' a.out not in cwd
>  -FAIL: gdb.base/attach.exp: do_attach_failure_tests: first attach
>  +PASS: gdb.base/attach.exp: do_attach_tests: attach1, after setting file
>  +PASS: gdb.base/attach.exp: do_attach_tests: attach2, with no file
>  +PASS: gdb.base/attach.exp: do_attach_tests: attach when process' a.out not in cwd
>  +PASS: gdb.base/attach.exp: do_attach_failure_tests: first attach
> 
> Change-Id: I359bdb25660c9a4d5d873e8771cfd1cd2a54c97b
> ---
>  gdb/infcmd.c                      |  5 ++++-
>  gdb/infrun.c                      | 13 +++++++++++++
>  gdb/infrun.h                      |  3 +++
>  gdb/testsuite/gdb.base/attach.exp | 26 ++++++--------------------
>  gdb/windows-nat.c                 |  7 +++++++
>  5 files changed, 33 insertions(+), 21 deletions(-)
> 
> diff --git a/gdb/infcmd.c b/gdb/infcmd.c
> index e9b58ce5521..cbf2373193c 100644
> --- a/gdb/infcmd.c
> +++ b/gdb/infcmd.c
> @@ -2722,7 +2722,10 @@ attach_command (const char *args, int from_tty)
>        return;
>      }
>    else
> -    attach_post_wait (from_tty, mode);
> +    {
> +      set_normal_stop_state_just_attached ();
> +      attach_post_wait (from_tty, mode);
> +    }
>  
>    disable_commit_resumed.reset_and_commit ();
>  }
> diff --git a/gdb/infrun.c b/gdb/infrun.c
> index 2e02642c52a..41ab3342ee3 100644
> --- a/gdb/infrun.c
> +++ b/gdb/infrun.c
> @@ -407,6 +407,19 @@ static process_stratum_target *target_last_proc_target;
>  static ptid_t target_last_wait_ptid;
>  static struct target_waitstatus target_last_waitstatus;
>  
> +/* See infrun.h.  */
> +
> +void
> +set_normal_stop_state_just_attached ()
> +{
> +  stop_print_frame = true;
> +  stopped_by_random_signal = 0;
> +
> +  target_waitstatus status;
> +  status.set_ignore ();
> +  set_last_target_status (nullptr, minus_one_ptid, status);
> +}
> +
>  void init_thread_stepping_state (struct thread_info *tss);
>  
>  static const char follow_fork_mode_child[] = "child";
> diff --git a/gdb/infrun.h b/gdb/infrun.h
> index b9b64aca45a..b707314fba6 100644
> --- a/gdb/infrun.h
> +++ b/gdb/infrun.h
> @@ -418,5 +418,8 @@ struct scoped_enable_commit_resumed
>    bool m_prev_enable_commit_resumed;
>  };
>  
> +/* Set up state for normal_stop after we just attached, on
> +   target_attach_no_wait targets.  */
> +extern void set_normal_stop_state_just_attached ();
>  
>  #endif /* GDB_INFRUN_H */
> diff --git a/gdb/testsuite/gdb.base/attach.exp b/gdb/testsuite/gdb.base/attach.exp
> index 0d1550a0541..484fa776ae4 100644
> --- a/gdb/testsuite/gdb.base/attach.exp
> +++ b/gdb/testsuite/gdb.base/attach.exp
> @@ -159,16 +159,9 @@ proc_with_prefix do_attach_failure_tests {} {
>      
>      # Verify that we can't double attach to the process.
>  
> -    set test "first attach"
> -    gdb_test_multiple "attach $testpid" "$test" {
> -	-re "Attaching to program.*`?$escapedbinfile'?, process $testpid.*main.*at .*$srcfile:.*$gdb_prompt $" {
> -	    pass "$test"
> -	}
> -	-re "Attaching to program.*`?$escapedbinfile\.exe'?, process $testpid.*\[Switching to thread $testpid\..*\].*$gdb_prompt $" {
> -	    # Response expected on Cygwin.
> -	    pass "$test"
> -	}
> -    }
> +    gdb_test "attach $testpid" \
> +	"Attaching to program.*`?${escapedbinfile}(\.exe)?'?, process $testpid.*main.*at .*$srcfile:.*" \
> +	"first attach"
>  
>      gdb_test "add-inferior" "Added inferior 2.*" "add empty inferior 2"
>      gdb_test "inferior 2" "Switching to inferior 2.*" "switch to inferior 2"
> @@ -252,16 +245,9 @@ proc_with_prefix do_attach_tests {} {
>  	}
>      }
>  
> -    set test "attach1, after setting file"
> -    gdb_test_multiple "attach $testpid" "$test" {
> -	-re "Attaching to program.*`?$escapedbinfile'?, process $testpid.*main.*at .*$srcfile:.*$gdb_prompt $" {
> -	    pass "$test"
> -	}
> -	-re "Attaching to program.*`?$escapedbinfile\.exe'?, process $testpid.*\[Switching to thread $testpid\..*\].*$gdb_prompt $" {
> -	    # Response expected on Cygwin
> -	    pass "$test"
> -	}
> -    }
> +    gdb_test "attach $testpid" \
> +	"Attaching to program.*`?${escapedbinfile}(\.exe)?'?, process $testpid.*main.*at .*$srcfile:.*" \
> +	"attach1, after setting file"
>  
>      # Verify that we can "see" the variable "should_exit" in the
>      # program, and that it is zero.
> diff --git a/gdb/windows-nat.c b/gdb/windows-nat.c
> index 939c5813aa7..0477731d40c 100644
> --- a/gdb/windows-nat.c
> +++ b/gdb/windows-nat.c
> @@ -1980,6 +1980,13 @@ windows_nat_target::attach (const char *args, int from_tty)
>  #endif
>  
>    do_initial_windows_stuff (pid, 1);
> +
> +  /* The thread that reports the initial breakpoint, and thus ends up
> +     as the selected thread when we get here, was injected into the
> +     inferior by DebugActiveProcess.  Switch to the main thread, which
> +     is normally more useful to the user than the injected thread.  */
> +  switch_to_thread (first_thread_of_inferior (current_inferior ()));
> +
>    target_terminal::ours ();
>  }
>  
> 
> base-commit: eb6c9310ee4d6cbde509d251fafb54ae45f5a5bf

Re: [PATCH] Improve attach on Windows

[Tom Tromey]

Pedro> I'm looking at the windows non-stop series again, trying to
Pedro> figure out where we were.

IIRC I reviewed some but not all of them.  I don't really recall though.

Pedro> There was one problem exposed by the AdaCore testsuite that I
Pedro> wasn't able to reproduce locally, so I don't know what to do
Pedro> about it.

I don't remember that but I am happy to try out patches in the local
setup.

Tom