This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GDB Ctrl-C Interrupt Fails WORKAROUND


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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]