[PATCH v2 6/6] QUIT processing w/ explicit sync_quit_force_run check

[Kevin Buettner <kevinb@redhat.com>]

Aside from the extension language updates, I found two other
cases which required explicit checks of sync_quit_force_run...

1) remote_fileio_request in gdb/remote-fileio.c:

The try block calls do_remote_fileio_request which can (in turn)
call one of the functions in remote_fio_func_map[].  Taking the
first one, remote_fileio_func_open(), we have the following call
path to maybe_quit():

  "_ZL23remote_fileio_func_openP13remote_targetPc"
    -> "_Z18target_read_memorymPhl"
    -> "_Z11target_readP10target_ops13target_objectPKcPhml"
    -> "_Z10maybe_quitv";

Since there is a path to maybe_quit(), we must ensure that the
catch block is not permitted to swallow a QUIT representing a
SIGTERM.

However, for this case, we must take care not to change the way
that Ctrl-C / SIGINT is handled; we want to send a suitable
EINTR reply to the remote target should that happen.  That
being the case, I added an explicit check for sync_quit_force_run;
if set, it rethrows the exception.

2) mi_execute_command in gdb/mi/mi-main.c:

The try block calls captured_mi_execute_command(); there exists
a call path to maybe_quit():

  "_ZL27captured_mi_execute_commandP6ui_outP8mi_parse"
    -> "_ZL14mi_cmd_executeP8mi_parse"
    -> "_Z17get_current_framev"
    -> "_ZL23get_prev_frame_always_1P10frame_info"
    -> "_ZL30frame_register_unwind_locationP10frame_infoiPiP9lval_typePmS1_"
    -> "_Z21frame_register_unwindP10frame_infoiPiS1_P9lval_typePmS1_Ph"
    -> "_Z24value_entirely_availableP5value"
    -> "_Z16value_fetch_lazyP5value"
    -> "_ZL23value_fetch_lazy_memoryP5value"
    -> "_Z17read_value_memoryP5valuelimPhm"
    -> "_Z10maybe_quitv";

That being the case, we can't allow the exception handler (catch block)
to swallow a gdb_exception_quit for SIGTERM.  However, it does seem
reasonable to output the exception via the mi interface so that some
suitable message regarding SIGTERM might be printed; therefore, I
do the check of sync_quit_force_run and the potential throw at the
end of the catch block.

(While doing all of this, it's occurred to me that these checks of the
global could be avoided by introducing a new exception for SIGTERM.
I haven't explored the implications of doing this though.)
---
 gdb/mi/mi-main.c    | 4 ++++
 gdb/remote-fileio.c | 8 +++++++-
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/gdb/mi/mi-main.c b/gdb/mi/mi-main.c
index e293dddc08d..74a02f2b58d 100644
--- a/gdb/mi/mi-main.c
+++ b/gdb/mi/mi-main.c
@@ -1962,6 +1962,10 @@ mi_execute_command (const char *cmd, int from_tty)
 	     somewhere.  */
 	  mi_print_exception (command->token, result);
 	  mi_out_rewind (current_uiout);
+
+	  /* Throw to a higher level catch for SIGTERM sent to GDB.  */
+	  if (sync_quit_force_run)
+	    throw;
 	}
 
       bpstat_do_actions ();
diff --git a/gdb/remote-fileio.c b/gdb/remote-fileio.c
index 9765093a723..e4965acaad6 100644
--- a/gdb/remote-fileio.c
+++ b/gdb/remote-fileio.c
@@ -1194,7 +1194,13 @@ remote_fileio_request (remote_target *remote, char *buf, int ctrlc_pending_p)
       catch (const gdb_exception &ex)
 	{
 	  if (ex.reason == RETURN_QUIT)
-	    remote_fileio_reply (remote, -1, FILEIO_EINTR);
+	    {
+	      /* Throw to a higher level catch for SIGTERM sent to GDB.  */
+	      if (sync_quit_force_run)
+		throw;
+
+	      remote_fileio_reply (remote, -1, FILEIO_EINTR);
+	    }
 	  else
 	    remote_fileio_reply (remote, -1, FILEIO_EIO);
 	}
-- 
2.31.1