Message-ID: <45EB1C2B.1090601@portugalmail.pt>
Date: Sun, 04 Mar 2007 19:21:15 +0000
From: Pedro Alves <pedro_alves AT portugalmail DOT pt>
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: <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>
In-Reply-To: <20070301025839.GA6915@trixie.casa.cgf.cx>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: 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/