Mail Archives: cygwin/2007/02/28/21:59:07
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/
- Raw text -