From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id r3e3IChH72XpvAIAWB0awg (envelope-from ) for ; Mon, 11 Mar 2024 14:02:16 -0400 Authentication-Results: simark.ca; dkim=fail reason="signature verification failed" (768-bit key; unprotected) header.d=tromey.com header.i=@tromey.com header.a=rsa-sha256 header.s=default header.b=g7wA7OeP; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 7655C1E0D2; Mon, 11 Mar 2024 14:02:16 -0400 (EDT) Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 5CA421E0AC for ; Mon, 11 Mar 2024 14:02:14 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 98D25385829B for ; Mon, 11 Mar 2024 18:02:13 +0000 (GMT) Received: from omta40.uswest2.a.cloudfilter.net (omta40.uswest2.a.cloudfilter.net [35.89.44.39]) by sourceware.org (Postfix) with ESMTPS id A07513858429 for ; Mon, 11 Mar 2024 18:01:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A07513858429 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=tromey.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=tromey.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org A07513858429 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=35.89.44.39 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1710180092; cv=none; b=rKl8svSt6tray3cf7f6O0B8ta0oUxXYtf2gvbQoNBjbwkFBg4OVLRCkB3JXM0xadEjDe2nIXnnRS97osT8nmkVI9kU9sVYqdxVx0JxPuxJPVjmZASm2k2UHeFBNNXAAEbcI8DLLnPrBhsKMW856xN4nhX/elyZG5vghdInU09uU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1710180092; c=relaxed/simple; bh=EXABXOXilxC61GCmkIP3RLLYmM5EDeT75Hf8npWtik4=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=uQfADCsgcjCCQxIJLlO/T84MtEWeyKOw6Y44NU77YaHJJAuKouEHduOYqTn11211qGRUMZ1y9vbeoZyEV1l3cPWPE68oEaBorN9fwbZbaXAv7vGKzGb4GmNueJ5VCLWzK5HYopQl8lIRxasLS4xkvwDSElle/cUDBsoVDabCpbk= ARC-Authentication-Results: i=1; server2.sourceware.org Received: from eig-obgw-5010a.ext.cloudfilter.net ([10.0.29.199]) by cmsmtp with ESMTPS id jYN3ryFYxPM1hjjxor9BCM; Mon, 11 Mar 2024 18:01:28 +0000 Received: from box5379.bluehost.com ([162.241.216.53]) by cmsmtp with ESMTPS id jjxnrJgnoNSidjjxorrX8V; Mon, 11 Mar 2024 18:01:28 +0000 X-Authority-Analysis: v=2.4 cv=WvMtM8fv c=1 sm=1 tr=0 ts=65ef46f8 a=ApxJNpeYhEAb1aAlGBBbmA==:117 a=ApxJNpeYhEAb1aAlGBBbmA==:17 a=K6JAEmCyrfEA:10 a=Qbun_eYptAEA:10 a=CCpqsmhAAAAA:8 a=sMQ4FR8_dAp_yZt-qO8A:9 a=_SAKN40iBToA:10 a=ul9cdbp4aOFLsgKbc677:22 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=tromey.com; s=default; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date:References :Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=a+bXk3QMJ6G7V/9ajCEGjVrl42l8eWi6fMIZ5VViVyg=; b=g7wA7OeP4tNgCYsMmLx8oRcumG upJJQX4XturKHGNeuXn+Uu0TlX/LP6BgUQ3gOKEWSNYte69Yce6fWmu+14esszI0eV581hVBl69rQ FesOLnm5Iu4pmo4k+IFHVh17c; Received: from 97-122-82-115.hlrn.qwest.net ([97.122.82.115]:37036 helo=murgatroyd) by box5379.bluehost.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96.2) (envelope-from ) id 1rjjxn-001vk7-16; Mon, 11 Mar 2024 12:01:27 -0600 From: Tom Tromey To: Guinevere Larsen Cc: Tom Tromey , gdb-patches@sourceware.org Subject: Re: [PATCH 1/4] gdb: make gdbarch store a vector of frame unwinders References: <20240306125135.766567-1-blarsen@redhat.com> <20240306125135.766567-2-blarsen@redhat.com> <87y1asr8c6.fsf@tromey.com> <5f8514e7-3df4-406b-ae77-4da30e8dd871@redhat.com> X-Attribution: Tom Date: Mon, 11 Mar 2024 12:01:26 -0600 In-Reply-To: <5f8514e7-3df4-406b-ae77-4da30e8dd871@redhat.com> (Guinevere Larsen's message of "Mon, 11 Mar 2024 11:51:54 +0100") Message-ID: <874jdcps09.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box5379.bluehost.com X-AntiAbuse: Original Domain - sourceware.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - tromey.com X-BWhitelist: no X-Source-IP: 97.122.82.115 X-Source-L: No X-Exim-ID: 1rjjxn-001vk7-16 X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: 97-122-82-115.hlrn.qwest.net (murgatroyd) [97.122.82.115]:37036 X-Source-Auth: tom+tromey.com X-Email-Count: 2 X-Org: HG=bhshared;ORG=bluehost; X-Source-Cap: ZWx5bnJvYmk7ZWx5bnJvYmk7Ym94NTM3OS5ibHVlaG9zdC5jb20= X-Local-Domain: yes X-CMAE-Envelope: MS4xfO0/USCdILepdKukKd6A+3fYUGOpqKi/M/F2qqakEy4hUOmJJCKtf7N/PKV3BZe3/g1DwBkJcVbC3PrJa08cM/zE9DL1duhQu7wCb2air5U5sYtL8ZJd I8aceL636A/j+34/voqgFunBx9r6qrd3ZfP2v8I9EWjgBHdqSzfkHPWVklA75wc4rKrILkS5HqPLB4c8rtmNXttdh8yjZxLpEN0= X-Spam-Status: No, score=-3015.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, JMQ_SPF_NEUTRAL, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no 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.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org > I guess you're right, but would it make any real difference to have > the gdbarch store a vector out right, or to store a vector in an > obfuscated way? I'm not really sure how I feel about it. In this case it's probably harmless. >> FWIW I think the real issue with obstack allocation isn't constructors >> but destruction. See https://sourceware.org/pipermail/gdb-patches/2024-February/206888.html > I see what you mean (though I don't necessarily understand why). I > would prefer if we could not restrict the destructors, but since GDB > doesn't ever dealloc gdbarches to begin with, I don't think that would > be a big issue either way. That's true for things that happen to be allocated on the gdbarch obstack right now, but not other obstacks, and perhaps not in the future if we ever decide a gdbarch should be deleted. FWIW the issue with non-trivial destructors is that when the obstack itself is destroyed, there's no mechanism for calling any of these. This could introduce leaks or whatever else. Tom