[RFA/RFC] QUIT doesn't seem to be working !?
Daniel Jacobowitz
drow@mvista.com
Mon Nov 17 01:00:00 GMT 2003
On Thu, Aug 28, 2003 at 10:41:16AM -0400, Daniel Jacobowitz wrote:
> 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.
Hi Elena,
Do you have any comments on this patch?
>
> > 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
>
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer
More information about the Gdb-patches
mailing list