From patchwork Tue Oct 25 11:19:41 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Tom de Vries X-Patchwork-Id: 59389 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 184BD3856976 for ; Tue, 25 Oct 2022 11:20:42 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 184BD3856976 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1666696842; bh=lvCaadagjjVDb6HrDQ68sPM4UiRQpnvJArtUkbDaah4=; h=To:Subject:Date:In-Reply-To:References:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To: From; b=JLzU8KGq9E8O7Tks/9Hu9ZjbtLOcSY8hmTu5Yn1Q1I9wqRhSP1z8P4cZXftbYI55H kmivlAbfhScSlXnlUa7Qt+0nsNQFgetczFuT4ooxAP+h1qX0uHBii/J4o4iHTtWBNE 5eM2MZpEl3H9UARrlznW/AbRPmA9qR3YPPJf1L0A= X-Original-To: gdb-patches@sourceware.org Delivered-To: gdb-patches@sourceware.org Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by sourceware.org (Postfix) with ESMTPS id 19D0D3857434 for ; Tue, 25 Oct 2022 11:19:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 19D0D3857434 Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out2.suse.de (Postfix) with ESMTPS id 058231F88E for ; Tue, 25 Oct 2022 11:19:46 +0000 (UTC) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id E6A2313A79 for ; Tue, 25 Oct 2022 11:19:45 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id sL5AN1HGV2O1dAAAMHmgww (envelope-from ) for ; Tue, 25 Oct 2022 11:19:45 +0000 To: gdb-patches@sourceware.org Subject: [RFC 1/5] [gdb] Catch gdb_exception_quit in munmap_list::~munmap_list Date: Tue, 25 Oct 2022 13:19:41 +0200 Message-Id: <20221025111945.23886-2-tdevries@suse.de> X-Mailer: git-send-email 2.35.3 In-Reply-To: <20221025111945.23886-1-tdevries@suse.de> References: <20221025111945.23886-1-tdevries@suse.de> MIME-Version: 1.0 X-Spam-Status: No, score=-12.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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-Patchwork-Original-From: Tom de Vries via Gdb-patches From: Tom de Vries Reply-To: Tom de Vries Errors-To: gdb-patches-bounces+patchwork=sourceware.org@sourceware.org Sender: "Gdb-patches" I tried out adding this exception slicing detection code in munmap_list::~munmap_list () in gdb/compile/compile-object-load.c: ... try { ... } catch (const gdb_exception_error &ex) { /* There's not much the user can do, so just ignore this. */ } + catch (const gdb_exception_quit &ex) + { + throw; + } + catch (const gdb_exception &ex) + { + gdb_assert (0); + } ... and ran into: ... gdb/compile/compile-object-load.c: In destructor ‘munmap_list::~munmap_list()’: gdb/compile/compile-object-load.c:64:4: error: \ throw will always call terminate() [-Werror=terminate] throw; ^~~~~ gdb/compile/compile-object-load.c:64:4: note: \ in C++11 destructors default to noexcept ... This raises the question of how a gdb_exception_quit should be handled in the destructor. Currently it's handled implicitly, and will result in std::terminate, which in absense of a std::set_terminate should call abort, after printing the type of the current exception, in other words gdb_exception_quit. We have a couple of choices to handle this explicitly: - std::terminate (no change in behaviour), - gdb_assert (false) (also calls abort, but with more info), or - ignore (as we do for gdb_exception_error) It seems to me that a gdb_exception_quit should not cause an abort, so handle explicitly by ignoring: ... - catch (const gdb_exception_error &ex) + catch (const gdb_exception &ex) ... Tested on x86_64-linux (though I don't have a setup with libcc1). --- gdb/compile/compile-object-load.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gdb/compile/compile-object-load.c b/gdb/compile/compile-object-load.c index 4c94ec53899..ca58775880b 100644 --- a/gdb/compile/compile-object-load.c +++ b/gdb/compile/compile-object-load.c @@ -54,7 +54,7 @@ munmap_list::~munmap_list () { gdbarch_infcall_munmap (target_gdbarch (), item.addr, item.size); } - catch (const gdb_exception_error &ex) + catch (const gdb_exception &ex) { /* There's not much the user can do, so just ignore this. */