Re: [PATCH] Improve attach on Windows

[Pedro Alves <pedro@palves.net>]

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