Re: [PATCH] Improve attach on Windows

[Hannes Domani <ssbssa@yahoo.de>]

 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