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 3C9F23858D35 for ; Thu, 12 Jan 2023 12:29:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3C9F23858D35 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=1673526546; 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=G6OIz3NErIUm489/z0cy28mi7lL/QK+rFCY2XEgrIro=; b=Ak1pPFzHaehUZnfriYg3rp03d8lYPWck0QvYQnJknctL0sa+gaVJVZaueErxDPLP6RxZ5F UUT2t/fZt8PUhKeb5IcoKsKZbTzaHLyrzF0OsMTMKtUIm8cgt/mxOJV6HinEX14Stcvtk+ KLkLXpZLKlWAgPr1v2YqyV+sMSLQOWw= 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-140-sGRTbzq_P-OuzokD8Hk7_Q-1; Thu, 12 Jan 2023 07:29:01 -0500 X-MC-Unique: sGRTbzq_P-OuzokD8Hk7_Q-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 3FDF185D061; Thu, 12 Jan 2023 12:29:01 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.223]) by smtp.corp.redhat.com (Postfix) with ESMTPS id ECC3540C2064; Thu, 12 Jan 2023 12:29:00 +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 30CCSvKi3415941 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Thu, 12 Jan 2023 13:28:58 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 30CCSuXd3415940; Thu, 12 Jan 2023 13:28:56 +0100 Date: Thu, 12 Jan 2023 13:28:56 +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.1 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 12:05:45PM +0000, Richard Sandiford wrote: > 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. 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). 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. > It would be good to remove the definition of RA_SIGNED_BIT as well, > so that people don't accidentally use it in future. Jakub