On Thu, Mar 01, 2007 at 01:12:21AM +0000, Pedro Alves wrote: >Christopher Faylor escreveu: >>On Thu, Mar 01, 2007 at 12:15:12AM +0000, Pedro Alves wrote: >>>Is there a reason DebugBreakProcess can't be used from inside gdb if >>>sending a ctrl-c with GenerateConsoleCtrlEvent (CTRL_C_EVENT, pid) >>>doesn't work? >> >>I suppose that it could be used for that but it might be tricky >>figuring out when it was required and when it wasn't. You wouldn't >>want to interrupt the process twice if it already saw the CTRL-C. >>Although, maybe if you used this you could tell the inferior process >>not to process CTRL-C at all via some CreateProcess setting. > >What about doing it the other way around? Use DebugBreakProcess if >available, and fallback to GenerateConsoleCtrlEvent?
? 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. >Is there anything internal to Cygwin that uses it? We could teach gdb >that the next BreakPoint inside kernel32 (, or whatever dll >DebugBreakProcess breaks in,) is mapped to SIGINT, remap the event, and >switch to the main thread, so the user doesn't see we stopped inside >kernel32. I think if gdb sends a break because it saw a CTRL-C and then gets a break from the sub-process it is safe for gdb to assume that the interrupt was a CTRL-C without needing to check where the break hit. I don't know about going to the effort of switching to thread 1, though. 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/
