X-Spam-Check-By:	sourceware.org
Date:	Sun, 4 Mar 2007 14:45:45 -0500
From:	Christopher Faylor <cgf-use-the-mailinglist-please AT cygwin DOT com>
To:	cygwin AT cygwin DOT com
Subject:	Re: GDB Ctrl-C Interrupt Fails WORKAROUND
Message-ID:	<20070304194545.GA4383@trixie.casa.cgf.cx>
Reply-To:	cygwin AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
References:	<E5AED0BA-EE62-4D97-96CE-8A96D0C0F559 AT qualcomm DOT com> <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> <45EB1C2B DOT 1090601 AT portugalmail DOT pt>
Mime-Version:	1.0
In-Reply-To:	<45EB1C2B.1090601@portugalmail.pt>
User-Agent:	Mutt/1.5.11
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Unsubscribe:	<mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com

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/

- Raw text -