From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10497 invoked by alias); 10 May 2008 15:31:25 -0000 Received: (qmail 10484 invoked by uid 22791); 10 May 2008 15:31:24 -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 15:31:06 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id DBD012A97D4 for ; Sat, 10 May 2008 11:31:04 -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 gMC4jzESRElu for ; Sat, 10 May 2008 11:31:04 -0400 (EDT) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id A33E82A97DE for ; Sat, 10 May 2008 11:31:04 -0400 (EDT) Received: by joel.gnat.com (Postfix, from userid 1000) id 9C449E7ACD; Sat, 10 May 2008 08:31:02 -0700 (PDT) Date: Sat, 10 May 2008 22:28:00 -0000 From: Joel Brobecker To: gdb-patches@sourceware.org Subject: Re: [RFC] control-c handling on Windows... Message-ID: <20080510153102.GE28890@adacore.com> References: <20080507205611.GB7421@adacore.com> <20080509202942.GA4386@ednor.casa.cgf.cx> <20080510013336.GC28890@adacore.com> <20080510043413.GA5429@ednor.casa.cgf.cx> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080510043413.GA5429@ednor.casa.cgf.cx> 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/msg00341.txt.bz2 Hi Chris, > I think the way this is handled in linux is by resetting the controlling > process group of the terminal to the pid of the inferior. On thinking > about this more, I think it probably makes more sense to bracket the > call with: > > SetConsoleCtrlHandler (NULL, TRUE); > retval = get_win32_debug_event (pid, ourstatus); > SetConsoleCtrlHandler (NULL, FALSE); > > That's almost equivalent to what linux does with process groups I think. > > Does the above work in your scenario, Joel? If so, I think this is > safe to check in. I think it does work. All my experiments at resuming the inferior after having interrupted it with C-c have been succesful. The only problem is that once in a while GDB still receives the SIGINT. This time, it doesn't cause the debugger to QUIT during the resume after handling the new-thread event like it used to, so we properly report the SIGINT event to the user: (gdb) cont Continuing. I = 10 I = 11 I = 12 [New thread 2348.0x1550] <<<--- pressed C-c Program received signal SIGINT, Interrupt. [Switching to thread 2348.0x1550] 0x7c87534d in KERNEL32!GetConsoleCharType (Quit (expect signal SIGINT when the program is resumed) However, because the SIGINT handler was called, we still get the unexpected "Quit (expect signal SIGINT when the program is resumed" message in the middle of printing the current frame. As I said earlier, it doesn't prevent the next resume to work properly. It's a little misleading but I think this is already a good improvement, so I suggest we go with your suggestion. 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. -- Joel