Re: [RFA/RFC] QUIT doesn't seem to be working !?

[Daniel Jacobowitz <drow@mvista.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