From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23051 invoked by alias); 12 Aug 2003 22:22:19 -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 23037 invoked from network); 12 Aug 2003 22:22:15 -0000 Received: from unknown (HELO takamaka.act-europe.fr) (142.179.108.108) by sources.redhat.com with SMTP; 12 Aug 2003 22:22:15 -0000 Received: by takamaka.act-europe.fr (Postfix, from userid 507) id 17EA9D2DAF; Tue, 12 Aug 2003 15:22:11 -0700 (PDT) Date: Tue, 12 Aug 2003 22:22:00 -0000 From: Joel Brobecker To: gdb-patches@sources.redhat.com Subject: [RFA/RFC] QUIT doesn't seem to be working !? Message-ID: <20030812222211.GC923@gnat.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="zhXaljGHf11kAtnf" Content-Disposition: inline User-Agent: Mutt/1.4i X-SW-Source: 2003-08/txt/msg00213.txt.bz2 --zhXaljGHf11kAtnf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-length: 1362 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? -- Joel --zhXaljGHf11kAtnf Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="event-top.c.diff" Content-length: 974 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. */ --zhXaljGHf11kAtnf--