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