From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20607 invoked by alias); 10 May 2008 18:00:42 -0000 Received: (qmail 20596 invoked by uid 22791); 10 May 2008 18:00:41 -0000 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 10 May 2008 18:00:14 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id E97E52A997B for ; Sat, 10 May 2008 14:00:12 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 2Mcbae-hIF+6 for ; Sat, 10 May 2008 14:00:12 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id 91FD52A99AD for ; Sat, 10 May 2008 14:00:12 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 79972E7ACD; Sat, 10 May 2008 11:00:10 -0700 (PDT) Date: Sun, 11 May 2008 13:31:00 -0000 From: Joel Brobecker To: gdb-patches@sourceware.org Subject: Re: [RFC] control-c handling on Windows... Message-ID: <20080510180010.GF28890@adacore.com> References: <20080507205611.GB7421@adacore.com> <20080509202942.GA4386@ednor.casa.cgf.cx> <20080510013336.GC28890@adacore.com> <20080510043413.GA5429@ednor.casa.cgf.cx> <20080510153102.GE28890@adacore.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080510153102.GE28890@adacore.com> User-Agent: Mutt/1.4.2.2i Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-05/txt/msg00343.txt.bz2 > If only I understood signals and terminals better, I would try to > understand the reason why GDB still gets the SIGINT despite all our > efforts. But, right now, I'm a little in the dark :(. I know that > Nicolas Roche, one of the engineers at AdaCore, has spent quite > a bit of time studying this sort of issues, so I'll see if I can > nudge him a little out of his busy schedule to share some of the ideas > he had. I spoke with Nico a little. He is pretty certain, based on what he read of the Windows documentation, that we cannot avoid having GDB receive the SIGINT. Apparently, the console is responsible for sending those signals, and its behavior cannot be changed. I wonder if there might be some sort of timing issue that causes the signal to sometimes be delivered after we stopped ignoring control events. In other words, some of the time, we receive the signal reasonably close to when we receive the debug event for the new thread, and so it gets ignored. But some other time, we receive the signal sufficiently after we got the debug event that we already got out of get_win32_debug_event and restored the regular SIGINT handler... That would explain why we're seeing the QUIT message. So the problem becomes when to handle the signal and when to ignore it. I'll keep thinking about it for a while, but I haven't found a solution yet. On a side note, utils.c:quit is: void quit (void) { #ifdef __MSDOS__ /* No steenking SIGINT will ever be coming our way when the program is resumed. Don't lie. */ fatal ("Quit"); #else if (job_control /* If there is no terminal switching for this target, then we can't possibly get screwed by the lack of job control. */ || current_target.to_terminal_ours == NULL) fatal ("Quit"); else fatal ("Quit (expect signal SIGINT when the program is resumed)"); #endif } Not sure when __MSDOS__ is defined, but perhaps we should extend that case to mingw & cygwin as well? At least we wouldn't get the "expect signal SIGINT when the program is resumed" part which I don't think can happen on Windows anymore. -- Joel