X-Spam-Check-By: sourceware.org Message-ID: <45EB1C2B.1090601@portugalmail.pt> Date: Sun, 04 Mar 2007 19:21:15 +0000 From: Pedro Alves User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; pt-BR; rv:1.8.0.9) Gecko/20061207 Thunderbird/1.5.0.9 Mnenhy/0.7.4.0 MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: Re: GDB Ctrl-C Interrupt Fails WORKAROUND References: <37FD7E0C-3F61-4EB2-B5A2-9C86C87A45DA AT qualcomm DOT com> <20060615150456 DOT GA7830 AT trixie DOT casa DOT cgf DOT cx> <20070228234326 DOT GD9444 AT ns1 DOT anodized DOT com> <45E61B10 DOT 4080208 AT portugalmail DOT pt> <20070301003511 DOT GA4537 AT trixie DOT casa DOT cgf DOT cx> <45E62875 DOT 3090507 AT portugalmail DOT pt> <20070301025839 DOT GA6915 AT trixie DOT casa DOT cgf DOT cx> In-Reply-To: <20070301025839.GA6915@trixie.casa.cgf.cx> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Antivirus: avast! (VPS 000721-1, 03-03-2007), Outbound message X-Antivirus-Status: Clean X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com 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/