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 A2060385843D for ; Thu, 12 Jan 2023 15:40:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A2060385843D 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 6445013D5; Thu, 12 Jan 2023 07:41:15 -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 5D9183F587; Thu, 12 Jan 2023 07:40:32 -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:40:31 +0000 In-Reply-To: (Jakub Jelinek's message of "Thu, 12 Jan 2023 16:34:22 +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.7 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 03:22:56PM +0000, Richard Sandiford wrote: >> 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. > > I can live even with that, I just hope it won't make code generation worse > on other targets. > Anyway, I understood aarch64 needs 2 states for the signing, so one would > be REG_TOGGLE_ON and the other anything else? The other is the default (no signing), so it needs to be REG_UNSAVED. > Users can always create (invalid?) unwind info where they save the magic > register, make it undefined etc. > > And > void bar (void), baz (void), boo (void), qux (void), corge (void); > enum { > REG_UNSAVED, > REG_SAVED_OFFSET, > REG_SAVED_REG, > REG_SAVED_EXP, > REG_SAVED_VAL_OFFSET, > REG_SAVED_VAL_EXP, > REG_UNDEFINED > #ifdef ANOTHER > , REG_TOGGLE_ON > #endif > }; > > void > foo (unsigned char c) > { > switch (c) > { > case REG_UNSAVED: > case REG_UNDEFINED: > #ifdef ANOTHER > case REG_TOGGLE_ON: > #endif > break; > > case REG_SAVED_OFFSET: > bar (); > break; > > case REG_SAVED_REG: > baz (); > break; > > case REG_SAVED_EXP: > boo (); > break; > > case REG_SAVED_VAL_OFFSET: > qux (); > break; > > case REG_SAVED_VAL_EXP: > corge (); > break; > } > } > suggests that it doesn't, already cfg pass turns the implicit default: > into something that covers even the REG_UNSAVED, REG_UNDEFINED and maybe > REG_TOGGLE_ON values into default: OK, that's good. Maybe having it behind a macro wouldn't be too bad though, if it comes to that. Thanks, Richard