GDB Ctrl-C Interrupt Fails WORKAROUND

[Pedro Alves]

Christopher Faylor wrote:

> ?  Maybe we're not talking about the same thing but I don't see why it
> matters what the order of function calls is.  If the inferior process
> has already responded to a CTRL-C you don't want it to get another
> interrupt.
>
>   

Yep, we were not talking about the same thing... I was under the 
impression that gdb always
saw the CTRL_C event, and was then resending it to the inferior in 
win32_stop, and then it was
the CTRL_C event sent with GenerateConsoleCtrlEvent that wasn't getting 
through.  I
was suggesting to use DebugBreakProcess in win32_stop, but that would 
solve a different problem.

I spend a little time trying to get a workaround for the CYGWIN=tty 
case, and I had some success, but
I don't think it is the right track.  I can only get it to work when 
loading the test app through a gdb loaded
in another gdb.
Here what I think it is happening in the CYGWIN="" case:
When using a console, and the user types ctrl-c, gdb first sees the 
CTRL_C event, and then,
the inferior sees it, which generates a DBG_CONTROL_C exception that gdb 
translates into a SIGINT.
If I set CYGWIN=tty in a cmd.exe based session, neither gdb nor the 
inferior see the CTRL_C
event, but, the inferior gdb does see a SIGINT signal, which normally 
just quits (you see the "Quit" in
gdb's console).  When there is a console, the signal is *not* seen by 
gdb, only the CTRL_C event.  So,
I've copied the SIGINT handler and the terminal_ours/terminal_inferior 
logic found gdb/remote.c into
win32-nat.c, and when the user types ctrl-c, I have a the inferior gdb 
send a send CTRL_C event to the
inferior test app using GenerateConsoleCtrlEvent.  The same gdb sees a 
DBG_CONTROL_C exception, as
if there was a console to begin with - the test app is stopped.
Now, if I try doing the same, but with only one gdb process involved, 
the SIGINT handler that is called is
always the one from the inferior process.  I guess something makes the 
first debuggee be the one that
catches signals.  To be clear,  in either:
- gdb (1) -> gdb (2) -> testapp (3)
or
- gdb (1) -> testapp (2)

It is (2) that gets the signal.

Anyway, it is not really my itch, so I'll leave it as that.  If someone 
wants the patch, just let me know.
Probably, having cygwin signals catchable in gdb would be time better 
spent, although that wouldn't
solve the MinGW/'gcc -mno-cygwin' side of the problem.  I wonder why it 
never went into
cygwin1.dll.  Chris, was it lack of time, or is there any major 
stumbling block?

Cheers,
Pedro Alves



--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/