From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id 3D7C43858D35 for ; Thu, 12 Jan 2023 12:08:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3D7C43858D35 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=arm.com Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 16B101477; Thu, 12 Jan 2023 04:09:04 -0800 (PST) Received: from localhost (e121540-lin.manchester.arm.com [10.32.99.50]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 11FA83F67D; Thu, 12 Jan 2023 04:08:20 -0800 (PST) From: Richard Sandiford To: Jakub Jelinek Mail-Followup-To: Jakub Jelinek ,Wilco Dijkstra , Martin =?utf-8?Q?Li=C5=A1ka?= , Kyrylo Tkachov , Szabolcs Nagy , GCC Patches , richard.sandiford@arm.com Cc: Wilco Dijkstra , Martin =?utf-8?Q?Li=C5=A1ka?= , Kyrylo Tkachov , Szabolcs Nagy , GCC Patches Subject: Re: [PATCH] libgcc: Fix uninitialized RA signing on AArch64 [PR107678] References: Date: Thu, 12 Jan 2023 12:08:19 +0000 In-Reply-To: (Richard Sandiford via Gcc-patches's message of "Thu, 12 Jan 2023 12:05:45 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-31.9 required=5.0 tests=BAYES_00,KAM_DMARC_NONE,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Richard Sandiford via Gcc-patches writes: > Jakub Jelinek writes: >> On Wed, Jan 11, 2023 at 11:59:27AM +0000, Wilco Dijkstra wrote: >>> Hi, >>> >>> > On 1/10/23 19:12, Jakub Jelinek via Gcc-patches wrote: >>> >> Anyway, the sooner this makes it into gcc trunk, the better, it breaks quite >>> >> a lot of stuff. >>> > >>> > Yep, please, we're also waiting for this patch for pushing to our gcc13 package. >>> >>> Well I'm waiting for an OK from a maintainer... I believe Jakub can approve it as well. >> >> Yes, I can, but am not sure it is appropriate. While I'm familiar with the >> unwinder, I'm not familiar with the pointer signing, and AArch64 has active >> maintainers, so I'd prefer to defer the review to them. > > I think my main question is: how clean vs hacky is it to use > REG_UNDEFINED as effectively a toggle bit, rather than using > REG_UNDEFINED for its intended purpose? > > In the review for earlier (May) patch, I'd asked whether it would > make sense to add a new enum. Would that be OK from a target-independent > point of view? E.g. maybe REG_TOGGLE_ON. > > Although we don't AFAIK support using DW_CFA_undefined with RA signing, > the failure mode would be non-obvious: it would effectively toggle the > bit on. > > It would be good to remove the definition of RA_SIGNED_BIT as well, > so that people don't accidentally use it in future. Sorry, just realised that the patch does do that. But please remove the comment too! Richard