This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFA/RFC] QUIT doesn't seem to be working !?
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: Joel Brobecker <brobecker at gnat dot com>
- Cc: gdb-patches at sources dot redhat dot com, ezannoni at redhat dot com
- Date: Thu, 28 Aug 2003 10:41:16 -0400
- Subject: Re: [RFA/RFC] QUIT doesn't seem to be working !?
- References: <20030812222211.GC923@gnat.com>
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 <brobecker@gnat.com>
>
> * 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