From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5114 invoked by alias); 21 Aug 2007 02:56:27 -0000 Received: (qmail 4946 invoked by uid 22791); 21 Aug 2007 02:56:26 -0000 X-Spam-Check-By: sourceware.org Received: from pool-72-70-61-242.bstnma.fios.verizon.net (HELO ednor.cgf.cx) (72.70.61.242) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 21 Aug 2007 02:56:21 +0000 Received: by ednor.cgf.cx (Postfix, from userid 201) id E7FAD2B352; Mon, 20 Aug 2007 22:56:07 -0400 (EDT) Date: Tue, 21 Aug 2007 02:56:00 -0000 From: Christopher Faylor To: Roland.Puntaier@br-automation.com, gdb@sourceware.org Subject: Re: gdb-6.6 mingw port hangs after Ctrl-C Message-ID: <20070821025607.GA14389@ednor.casa.cgf.cx> Mail-Followup-To: Roland.Puntaier@br-automation.com, gdb@sourceware.org References: <20070820162439.GA30242@caradoc.them.org> <20070820193128.GA17272@caradoc.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070820193128.GA17272@caradoc.them.org> User-Agent: Mutt/1.5.16 (2007-06-09) Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-08/txt/msg00145.txt.bz2 On Mon, Aug 20, 2007 at 03:31:28PM -0400, Daniel Jacobowitz wrote: >On Mon, Aug 20, 2007 at 10:16:12PM +0300, Eli Zaretskii wrote: >> The way to fix this is to make the signal handler stop the main thread >> as the first thing it does. Then you have a Posix-compliant program >> again. I did something similar for the MinGW port of GNU Make. > >Is there any way to force the other thread to longjmp? Otherwise, >just stopping it isn't enough - you don't have the right stack. >Erm, maybe it would work anyway... longjmping from one thread to >another scares me a bit, though. This is why Cygwin's signal handling code is so complicated. You can stop another thread with a "SuspendThread()" call and you can cause the thread to resume in another location with a "ResumeThread()" by changing the EIP that is passed to it. However, if you do that while you are in the middle of a low-level Windows function which, say, holds a mutex, then you are going to eventually run into problems. It's possible that this isn't a big problem for newer NT-based OSes but it was a show-stopper for the older versions of Windows and older versions of Windows NT. Cygwin works around this by not allowing itself to be suspended within a Cygwin1.dll function and checking for signal redirection at the end of any Cygwin function which references Windows. If it notices that a signal came in then, instead of returning, the function will jump to the appropriate signal handler. If the signal came in while user-level code was executing then the main thread is suspended and resumed at a new location which fixes up the stack so that the equivalent of a longjmp takes place. You *might* be able to make gdb do something similar to all of this but it would obviously be a lot of work. cgf