From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id 5C87D385741A for ; Sun, 22 Aug 2021 23:24:52 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5C87D385741A Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-291-LZF6Ct8cO0OQjRWAvxXyIA-1; Sun, 22 Aug 2021 19:24:50 -0400 X-MC-Unique: LZF6Ct8cO0OQjRWAvxXyIA-1 Received: from smtp.corp.redhat.com (int-mx07.intmail.prod.int.phx2.redhat.com [10.5.11.22]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 74D9A824F8B; Sun, 22 Aug 2021 23:24:49 +0000 (UTC) Received: from f34-1.lan (ovpn-112-47.phx2.redhat.com [10.3.112.47]) by smtp.corp.redhat.com (Postfix) with ESMTP id 3CF3D10013C1; Sun, 22 Aug 2021 23:24:49 +0000 (UTC) From: Kevin Buettner To: gdb-patches@sourceware.org Subject: [PATCH v2 6/6] QUIT processing w/ explicit sync_quit_force_run check Date: Sun, 22 Aug 2021 16:20:04 -0700 Message-Id: <20210822231959.184061-7-kevinb@redhat.com> In-Reply-To: <20210822231959.184061-1-kevinb@redhat.com> References: <20210822231959.184061-1-kevinb@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.84 on 10.5.11.22 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="US-ASCII" X-Spam-Status: No, score=-13.0 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Aug 2021 23:24:53 -0000 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