Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Fred Fish <fnf@specifix.com>
To: Daniel Jacobowitz <drow@false.org>
Cc: GDB Patches <gdb-patches@sources.redhat.com>
Subject: Re: [RFC] Patch for QUIT macro support
Date: Sun, 21 Jan 2007 19:23:00 -0000	[thread overview]
Message-ID: <200701211223.16680.fnf@specifix.com> (raw)
In-Reply-To: <20070121174418.GJ12463@nevyn.them.org>

[-- Attachment #1: Type: text/plain, Size: 545 bytes --]

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




[-- Attachment #2: p --]
[-- Type: text/x-diff, Size: 1603 bytes --]

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 ();
 }
 

  reply	other threads:[~2007-01-21 19:23 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-13 12:43 Fred Fish
2006-10-13 13:22 ` Fred Fish
2006-10-13 13:30   ` Daniel Jacobowitz
2006-10-13 13:49     ` Fred Fish
2007-01-21 17:44       ` Daniel Jacobowitz
2007-01-21 19:23         ` Fred Fish [this message]
     [not found]       ` <200610151800.k9FI0fDS016688@elgar.sibelius.xs4all.nl>
2007-01-22 14:41         ` Fred Fish
2007-02-08 14:34           ` Daniel Jacobowitz
2007-02-08 20:49             ` Nick Roberts
2007-02-08 21:17               ` Fred Fish
2007-02-08 21:51                 ` Nick Roberts
2006-10-13 14:58     ` Fred Fish
2007-02-08 14:34       ` Daniel Jacobowitz
2006-10-16  0:08 Nick Roberts

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200701211223.16680.fnf@specifix.com \
    --to=fnf@specifix.com \
    --cc=drow@false.org \
    --cc=gdb-patches@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox