From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=suse.de 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) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_rsa; t=1666696786; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=lvCaadagjjVDb6HrDQ68sPM4UiRQpnvJArtUkbDaah4=; b=FZJWuEEj12iUw1JNjtZHWNXu5tB+TRbRD8OUg7wB3PGdf+a2ce5V9OI8+RmRwRxNlLBJBm 4Hy0ZdCpw3cZPOhGSUPC5bmY+7H1mWF2mXU93XcjPzv1swOrtqZSW1xZkAEVtvZjy+JO/d BwUBPGX9+CUW4s9qXR+FqKFHE/DkGRc= DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=suse.de; s=susede2_ed25519; t=1666696786; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=lvCaadagjjVDb6HrDQ68sPM4UiRQpnvJArtUkbDaah4=; b=ynoQ7jZcCr1aqd5T3cuyFS+jip2Pkc+pMJ5objS+1kDVQ2a47bPN8Dk+r/MeRfIbMZNieK 43n4LQvkMBsJAzAQ== 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 From: Tom de Vries 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 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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 List-Id: 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. */ -- 2.35.3