From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9493 invoked by alias); 28 Aug 2003 14:41:22 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 9403 invoked from network); 28 Aug 2003 14:41:20 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 28 Aug 2003 14:41:20 -0000 Received: from drow by nevyn.them.org with local (Exim 4.22 #1 (Debian)) id 19sNxc-0000nY-Qg; Thu, 28 Aug 2003 10:41:16 -0400 Date: Thu, 28 Aug 2003 14:41:00 -0000 From: Daniel Jacobowitz To: Joel Brobecker Cc: gdb-patches@sources.redhat.com, ezannoni@redhat.com Subject: Re: [RFA/RFC] QUIT doesn't seem to be working !? Message-ID: <20030828144116.GC2731@nevyn.them.org> Mail-Followup-To: Joel Brobecker , gdb-patches@sources.redhat.com, ezannoni@redhat.com References: <20030812222211.GC923@gnat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030812222211.GC923@gnat.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-08/txt/msg00508.txt.bz2 On Tue, Aug 12, 2003 at 03:22:11PM -0700, Joel Brobecker wrote: > Hello, > > it's bizarre, we noticed that we were unable to interrupt certain > commands that can be time greedy. For instance, when messing up in the > addresses given to the "disass" command, it can take GDB a loooooong > time to print all instructions. Unexpectedly, hitting Control-C did not > interrupt the command. > > I see in disassemble_command() that there is a call to QUIT in the while > loop that prints all instructions. But this macro tests for quit_flag > to see if we should stop now or not. However, handle_sigint() does > not set this flag when Control-C is pressed, unless immediate_quit is > set. But immediate_quit is not really what we are looking for, because > it tells GDB that SIGINT events should be processed immediately, which > obviously means that GDB does not wait for the next call to QUIT to > perform the abortion. > > So far, what handle_sigint() does is set the "ready" flag in GDB's > SIGINT async signal handler. This flag seems to take effect only > at the top-level loop level. So in our case, its effect arrives too > late. > > So I couldn't understand how QUIT was working.... > > I applied the following change, which allows GDB to aboart at QUIT > points if the user has pressed C-c. But I feel like I'm missing > something... > > 2003-08-12 J. Brobecker > > * event-top.c (handle_sigint): Set quit_flag. > > Comments? Ok to apply? I see two functions which are intended to handle SIGINT. One of them is handle_sigint; the other is request_quit. If event_loop_p, we use the async version, which does not quit immediately. This is the case unless gdb is started with --noasync. The comments in handle_sigint suggest that deferring the C-c to the next time through the event loop is desired behavior. I'm not entirely sure why. It loses the use of the QUIT macro entirely. There's a whole lot of complicated async infrastructure in event-top.c and event-loop.c but it seems that the async handlers are never called except from gdb_do_one_event, and I don't see any actual asynchronous way of getting there. Elena seems to have written most of this code. She might have a better idea of how this is supposed to work - and conveniently, she's listed as its maintainer, too :) I suspect your patch is right, but I don't know if some additional cleanup is required for the asynchronous signal handlers, to prevent the quit from being processed twice. > Index: event-top.c > =================================================================== > RCS file: /nile.c/cvs/Dev/gdb/gdb-5.3/gdb/event-top.c,v > retrieving revision 1.1 > diff -u -p -r1.1 event-top.c > --- event-top.c 16 Jan 2003 09:46:22 -0000 1.1 > +++ event-top.c 12 Aug 2003 21:27:57 -0000 > @@ -967,9 +967,14 @@ handle_sigint (int sig) > if (immediate_quit) > async_request_quit (0); > else > - /* If immediate quit is not set, we process SIGINT the next time > - through the loop, which is fine. */ > - mark_async_signal_handler_wrapper (sigint_token); > + { > + /* If immediate quit is not set, we process SIGINT the next time > + through the loop, which is fine. */ > + mark_async_signal_handler_wrapper (sigint_token); > + /* We can also process the signal at certain specific locations > + which are explicitely marked by a call to QUIT. */ > + quit_flag = 1; > + } > } > > /* Do the quit. All the checks have been done by the caller. */ -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer