On Sun, Mar 04, 2007 at 07:21:15PM +0000, Pedro Alves wrote: >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. > >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?
The code in question is under a CGF conditional in exceptions.cc. It does not work right and, since this isn't a major issue for me, I haven't investigated it lately. I think that it is possible to make things work but anyone who does will have to understand gdb and cygwin signals. cgf -- 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/
