Re: [PATCH] Improve attach on Windows

[Hannes Domani <ssbssa@yahoo.de>]

 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