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 E7F793858C66 for ; Thu, 12 Jan 2023 15:22:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org E7F793858C66 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 C232513D5; Thu, 12 Jan 2023 07:23:40 -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 BCEA43F587; Thu, 12 Jan 2023 07:22:57 -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 15:22:56 +0000 In-Reply-To: (Jakub Jelinek's message of "Thu, 12 Jan 2023 15:39:58 +0100") 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.8 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: Jakub Jelinek writes: > On Thu, Jan 12, 2023 at 01:28:59PM +0100, Jakub Jelinek wrote: >> > 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. >> >> We don't install unwind-dw2.h nor give user code access to the how array >> (and it just lives on the stack of __frame_state_for/uw_init_context_1 >> functions and address of it is passed to functions called from it), >> so I hope all this is private to the libgcc unwinder. After all, otherwise >> e.g. the change how "how" is represented couldn't be done. >> That said, if new enum entries are added in the generic code, then >> I think uw_update_context_1 will warn about unhandled case in a switch, >> unless we e.g. change >> case REG_UNSAVED: >> case REG_UNDEFINED: >> break; >> to >> default: >> break; >> (and provided that the new enums would want such handling). If we have a new enum, I think we should handle it explicitly. The fact that the information isn't propagated between frames is a key part of the semantics. >> Another option is to just define the arch dependent value for how field >> in the arch code, right now it is unsigned char type, so using say >> (unsigned char) ~0 or (unsigned char) ~0 and (unsigned char) ~1 as arch >> specific values might be ok too. > > Yet another option would be to define 1-2 extra REG_ values in the generic > unwind-dw2.h header, but name them > REG_ARCH_SPECIFIC_1, > REG_ARCH_SPECIFIC_2, > or so, and then the machine specific code can > #define REG_AARCH64_TOGGLE_ON REG_ARCH_SPECIFIC_1 > Of course, all this depends on whether the arch specific codes can be > handled in uw_update_context_1 by doing break; there and nothing else. Yeah, personally I'd prefer for target-independent code to provide the toggle representation, even if it isn't widely used. Thanks, Richard