From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 5AF243858C74 for ; Thu, 12 Jan 2023 15:34:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5AF243858C74 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1673537672; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=6v57rjcckiHJrG437AVdGiQJMWymO0RDbeEWesuP12g=; b=WIPF8cfPUYhq9KF7VnucUTNkUREZAg7r74lhZwgP+oLz46GSaDcfIlQVPzU1DnB+jfoh9W EqTNzvMyuDcI7wL4KC/IwogViqgnEPrxnIHRIuteSSJ3ygscKo/t+OASnT8fd37/QTyRHZ UKmplf2shgDcWuArx3ilDYnh0/ErtzE= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-86-NrmsISD-OJmm-mF422gYZg-1; Thu, 12 Jan 2023 10:34:28 -0500 X-MC-Unique: NrmsISD-OJmm-mF422gYZg-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 16F95101A52E; Thu, 12 Jan 2023 15:34:28 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.223]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C3CAE1121314; Thu, 12 Jan 2023 15:34:27 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 30CFYOAx3423156 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Thu, 12 Jan 2023 16:34:24 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 30CFYMK73423155; Thu, 12 Jan 2023 16:34:22 +0100 Date: Thu, 12 Jan 2023 16:34:22 +0100 From: Jakub Jelinek To: Wilco Dijkstra , Martin =?utf-8?B?TGnFoWth?= , Kyrylo Tkachov , Szabolcs Nagy , GCC Patches , richard.sandiford@arm.com Subject: Re: [PATCH] libgcc: Fix uninitialized RA signing on AArch64 [PR107678] Message-ID: Reply-To: Jakub Jelinek References: MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.3 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_MANYTO,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,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: 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? 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: Jakub