binutils-gdb/gdb/inf-loop.c
Kevin Buettner b1ffd1124a Catch gdb_exception_error instead of gdb_exception (in many places)
As described in the previous commit for this series, I became
concerned that there might be instances in which a QUIT (due to either
a SIGINT or SIGTERM) might not cause execution to return to the top
level.  In some (though very few) instances, it is okay to not
propagate the exception for a Ctrl-C / SIGINT, but I don't think that
it is ever okay to swallow the exception caused by a SIGTERM.
Allowing that to happen would definitely be a deviation from the
current behavior in which GDB exits upon receipt of a SIGTERM.

I looked at all cases where an exception handler catches a
gdb_exception.  Handlers which did NOT need modification were those
which satisifed one or more of the following conditions:

  1) There is no call path to maybe_quit() in the try block.  I used a
     static analysis tool to help make this determination.  In
     instances where the tool didn't provide an answer of "yes, this
     call path can result in maybe_quit() being called", I reviewed it
     by hand.

  2) The catch block contains a throw for conditions that it
     doesn't want to handle; these "not handled" conditions
     must include the quit exception and the new "forced quit" exception.

  3) There was (also) a catch for gdb_exception_quit.

Any try/catch blocks not meeting the above conditions could
potentially swallow a QUIT exception.

My first thought was to add catch blocks for gdb_exception_quit and
then rethrow the exception.  But Pedro pointed out that this can be
handled without adding additional code by simply catching
gdb_exception_error instead.  That's what this patch series does.

There are some oddball cases which needed to be handled differently,
plus the extension languages, but those are handled in later patches.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26761
Tested-by: Tom de Vries <tdevries@suse.de>
Approved-by: Pedro Alves <pedro@palves.net>
2023-02-27 16:20:39 -07:00

92 lines
2.8 KiB
C

/* Handling of inferior events for the event loop for GDB, the GNU debugger.
Copyright (C) 1999-2023 Free Software Foundation, Inc.
Written by Elena Zannoni <ezannoni@cygnus.com> of Cygnus Solutions.
This file is part of GDB.
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 3 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program. If not, see <http://www.gnu.org/licenses/>. */
#include "defs.h"
#include "inferior.h"
#include "infrun.h"
#include "gdbsupport/event-loop.h"
#include "event-top.h"
#include "inf-loop.h"
#include "remote.h"
#include "language.h"
#include "gdbthread.h"
#include "interps.h"
#include "top.h"
#include "observable.h"
/* General function to handle events in the inferior. */
void
inferior_event_handler (enum inferior_event_type event_type)
{
switch (event_type)
{
case INF_REG_EVENT:
fetch_inferior_event ();
break;
case INF_EXEC_COMPLETE:
if (!non_stop)
{
/* Unregister the inferior from the event loop. This is done
so that when the inferior is not running we don't get
distracted by spurious inferior output. */
if (target_has_execution () && target_can_async_p ())
target_async (false);
}
/* Do all continuations associated with the whole inferior (not
a particular thread). */
if (inferior_ptid != null_ptid)
current_inferior ()->do_all_continuations ();
/* When running a command list (from a user command, say), these
are only run when the command list is all done. */
if (current_ui->async)
{
check_frame_language_change ();
/* Don't propagate breakpoint commands errors. Either we're
stopping or some command resumes the inferior. The user will
be informed. */
try
{
bpstat_do_actions ();
}
catch (const gdb_exception_error &e)
{
/* If the user was running a foreground execution
command, then propagate the error so that the prompt
can be reenabled. Otherwise, the user already has
the prompt and is typing some unrelated command, so
just inform the user and swallow the exception. */
if (current_ui->prompt_state == PROMPT_BLOCKED)
throw;
else
exception_print (gdb_stderr, e);
}
}
break;
default:
gdb_printf (gdb_stderr, _("Event type not recognized.\n"));
break;
}
}