From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18068 invoked by alias); 21 Aug 2007 17:42:03 -0000 Received: (qmail 17910 invoked by uid 22791); 21 Aug 2007 17:42:02 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 21 Aug 2007 17:42:00 +0000 Received: (qmail 6081 invoked from network); 21 Aug 2007 17:41:58 -0000 Received: from unknown (HELO localhost) (jimb@127.0.0.2) by mail.codesourcery.com with ESMTPA; 21 Aug 2007 17:41:58 -0000 To: Roland.Puntaier@br-automation.com Cc: gdb@sourceware.org Subject: Re: gdb-6.6 mingw port hangs after Ctrl-C References: <20070820162439.GA30242@caradoc.them.org> <20070820193128.GA17272@caradoc.them.org> <20070821025607.GA14389@ednor.casa.cgf.cx> From: Jim Blandy Date: Tue, 21 Aug 2007 17:42:00 -0000 In-Reply-To: <20070821025607.GA14389@ednor.casa.cgf.cx> (Christopher Faylor's message of "Mon, 20 Aug 2007 22:56:07 -0400") Message-ID: User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-IsSubscribed: yes 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/msg00154.txt.bz2 Christopher Faylor writes: > 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. GDB's quit_flag / immediate_quit / QUIT macro is set up for polling a flag and handling interrupts at safe points. The issue at hand here is that we need C-c to interrupt the main thread as it reads from the remote host. That could be a pipe, a socket, or a serial port. Do you know how one can safely interrupt each of these kinds of reads in Windows?