Re: [PATCH] [RFC] Move SetConsoleCtrlHandler calls to async thread

[Hannes Domani <ssbssa@yahoo.de>]

 Am Donnerstag, 1. Dezember 2022, 18:30:33 MEZ hat Tom Tromey <tromey@adacore.com> Folgendes geschrieben:

> >>>>> "Hannes" == Hannes Domani via Gdb-patches <gdb-patches@sourceware.org> writes:
>
> Hannes> Ctrl-C and Ctrl-Break don't work any more since the async commit, so I've tried
> Hannes> to move the SetConsoleCtrlHandler calls.
> Hannes> Now Ctrl-C seems to work, but Ctrl-Break completely stop both gdb and the
> Hannes> inferior (if new-console is disabled).
>
> Hannes> I'm not sure what's the proper fix is here, please advise.
>
> In my normal environment (ssh to a Windows machine), none of this has
> ever worked at all.  I don't know why, something to do with ssh and/or
> cygwin.
>
> Anyway, I managed to test C-c by using remmina (RDP client) and then
> running gdb in the console provided there.  I used conemu which I gather
> opened some kind of Cygwin shell.

I'm not sure if C-c works the same inside of Cygwin.


> According to winver this machine is "Windows Server 2016".
>
> I tried a few versions:
>
> 1. AdaCore internal gdb from before the target async patches.  (AdaCore
>   has some local changes, but nothing relevant to this problem.)
>
> 2. AdaCore gdb corresponding to git master, plus your other recent
>   windows-nat patches.
>
> 3. #2 plus your C-c patch.
>
> When I use "run" in gdb, control-c and control-break worked fine with 1
> and 2.  (FWIW I used the on-screen keyboard to send control-break, I
> don't know any other way to do it.)
>
> When I use "attach", neither 1 nor 2 work at all -- but your patch does,
> but only for C-c.  C-break just makes gdb exit.

Yes, that C-break just exits gdb is the issue I meant, that didn't happen
before.


> Now, TBH, I find all of this surprising, because on seeing your patch, I
> agree that the target async work should cause a problem here.  And, I
> don't understand why your patch fixes the "attach" behavior.
>
> With your patch installed, C-c still works, but C-break does not.  I
> don't understand why this happens.  My understanding is that
> SetConsoleCtrlHandler intercepts C-break as well, and the body of that
> callback hasn't changed.
>
> One other thing I don't understand is that C-c doesn't cause gdb to exit
> when it is waiting at the prompt.  Instead I get this quit message:
>
>     throw_quit ("Quit (expect signal SIGINT when the program is resumed)");

I don't think I've ever seen this.
When I press C-c on the gdb prompt, nothing at all happens, which is also
what I expected.


> Like, if this happens, do we really need ctrl_c_handler for the C-c case
> at all?  (Maybe we do need the handler because windows-nat doesn't use
> set_sigint_trap.)  And should gdb default to handling ctrl-break as
> well?  Like, I wonder if there's a race between something like the call
> to signal in child_terminal_inferior and installing the C-c handler.
>
> The comment in windows-nat says:
>
>         [...]  There are two
>         possible situations:
>
>           - The debugger and the program do not share the console, in
>             which case the Ctrl-c event only reached the debugger.
>             In that case, the ctrl_c handler will take care of
>             interrupting the inferior.  Note that this case is
>             working starting with Windows XP.  For Windows 2000,
>             Ctrl-C should be pressed in the inferior console.
>
> Maybe the 'attach' issue is a known problem?
>
> Anyway.  I've learned that there's a lot in this area I don't
> understand.  I think the first thing to do is understand why we get
> different results.  I wonder what I could change here to reproduce the
> problem.  Maybe I shouldn't be using conemu but instead something else?

Note that it also makes a difference if you started a process with
'set new-console on' enabled (which is what I always have set).


Hannes