Re: [PATCH] Improve attach on Windows

[Pedro Alves <pedro@palves.net>]

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