Mail Archives: cygwin/2007/03/04/14:22:48
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/
- Raw text -