X-Spam-Check-By: sourceware.org Date: Wed, 28 Feb 2007 21:58:39 -0500 From: Christopher Faylor To: cygwin@cygwin.com Subject: Re: GDB Ctrl-C Interrupt Fails WORKAROUND Message-ID: <20070301025839.GA6915@trixie.casa.cgf.cx> Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com References: <37FD7E0C-3F61-4EB2-B5A2-9C86C87A45DA@qualcomm.com> <20060615150456.GA7830@trixie.casa.cgf.cx> <20070228234326.GD9444@ns1.anodized.com> <45E61B10.4080208@portugalmail.pt> <20070301003511.GA4537@trixie.casa.cgf.cx> <45E62875.3090507@portugalmail.pt> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45E62875.3090507@portugalmail.pt> User-Agent: Mutt/1.5.11 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Delivered-To: mailing list cygwin@cygwin.com 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/