From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 443 invoked by alias); 21 Jan 2007 19:23:38 -0000 Received: (qmail 435 invoked by uid 22791); 21 Jan 2007 19:23:37 -0000 X-Spam-Check-By: sourceware.org Received: from w099.z064220152.sjc-ca.dsl.cnc.net (HELO bluesmobile.corp.specifix.com) (64.220.152.99) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sun, 21 Jan 2007 19:23:31 +0000 Received: from fishpond.diveadx.com (bluesmobile.corp.specifix.com [192.168.1.32]) by bluesmobile.corp.specifix.com (Postfix) with ESMTP id A88313B81B; Sun, 21 Jan 2007 11:23:21 -0800 (PST) From: Fred Fish Reply-To: fnf@specifix.com To: Daniel Jacobowitz Subject: Re: [RFC] Patch for QUIT macro support Date: Sun, 21 Jan 2007 19:23:00 -0000 User-Agent: KMail/1.9.5 Cc: GDB Patches References: <200610130543.25806.fnf@specifix.com> <200610130648.31875.fnf@specifix.com> <20070121174418.GJ12463@nevyn.them.org> In-Reply-To: <20070121174418.GJ12463@nevyn.them.org> MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="Boundary-00=_k27sF1YZYs2cE7T" Message-Id: <200701211223.16680.fnf@specifix.com> 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: 2007-01/txt/msg00445.txt.bz2 --Boundary-00=_k27sF1YZYs2cE7T Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-length: 545 On Sunday 21 January 2007 10:44, Daniel Jacobowitz wrote: > > Here's the patch I'm now testing. > > Hey, Fred, did anything ever come of this? I've attached the patch we applied locally. Other than the comment about not putting in the comments, there weren't any other replies to my last posting or any specific approval posted. I got busy and forgot about following up any more. I guess I could clean up the comments and post again to get official approval from another maintainer. Should be able to do that later this evening. -Fred --Boundary-00=_k27sF1YZYs2cE7T Content-Type: text/x-diff; charset="iso-8859-1"; name="p" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="p" Content-length: 1603 Index: event-top.c =================================================================== RCS file: /services/cvs/cvsroot/latest/gdb/gdb/event-top.c,v retrieving revision 1.1.1.8 retrieving revision 1.1.1.6.2.2 diff -u -p -r1.1.1.8 -r1.1.1.6.2.2 --- event-top.c 16 Jan 2007 01:05:29 -0000 1.1.1.8 +++ event-top.c 11 Dec 2006 18:23:23 -0000 1.1.1.6.2.2 @@ -961,6 +961,16 @@ handle_sigint (int sig) { signal (sig, handle_sigint); + /* We used to set the quit flag in async_request_quit, which is either + called when immediate_quit is 1, or when we get back to the event + loop. This is wrong, because you could be running in a loop reading + in symfiles or something, and it could be quite a while before you + get to the event loop. Instead, set quit_flag to 1 here, then mark + the sigint handler as ready. Then if somebody calls QUIT before you + get to the event loop, they will unwind as expected. */ + + quit_flag = 1; + /* If immediate_quit is set, we go ahead and process the SIGINT right away, even if we usually would defer this to the event loop. The assumption here is that it is safe to process ^C immediately if @@ -989,7 +999,14 @@ handle_sigterm (int sig) void async_request_quit (gdb_client_data arg) { - quit_flag = 1; + /* If the quit_flag has gotten reset back to 0 by the time we get + back here, that means that an exception was thrown to unwind + the current command before we got back to the event loop. So + there is no reason to call quit again here. */ + + if (quit_flag == 0) + return; + quit (); } --Boundary-00=_k27sF1YZYs2cE7T--