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 0C16B385843A for ; Thu, 2 Feb 2023 11:41:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0C16B385843A Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=foss.arm.com Authentication-Results: sourceware.org; spf=none smtp.mailfrom=foss.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 EFBB2C14; Thu, 2 Feb 2023 03:42:30 -0800 (PST) Received: from [10.57.46.199] (unknown [10.57.46.199]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id C770E3F64C; Thu, 2 Feb 2023 03:41:47 -0800 (PST) Message-ID: <35a62c0a-12de-8841-cb93-6ff4cfa4495e@foss.arm.com> Date: Thu, 2 Feb 2023 11:41:46 +0000 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Subject: Re: [PATCH] libc: arm: Implement setjmp GCC backwards compatibility. Content-Language: en-GB To: "Victor L. Do Nascimento" , newlib@sourceware.org Cc: richard.earnshaw@arm.com References: From: Richard Earnshaw In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3495.7 required=5.0 tests=BAYES_00,GIT_PATCH_0,KAM_DMARC_STATUS,KAM_LAZY_DOMAIN_SECURITY,NICE_REPLY_A,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 01/02/2023 15:10, Victor L. Do Nascimento wrote: > When compiling Newlib for arm targets with GCC 12.1 onward, the passing > of architecture extension information to the assembler is automatic, > making the use of `.fpu' directives instructions in assembly files > redundant. > > With older versions of GCC, however, the .fpu directive must be > hard-coded into the arm/setjmp.S file to allow the assembly of > instructions concerning the storage and subsequent reloading of the > floating point registers to/from the jump buffer, respectively. > > This patch conditionally adds the `.fpu vfpxd' directive based on > compile-time preprocessor macros concerning GCC version and target > architectural features, such that both the assembly and linking of > setjmp.S succeeds for older versions of Newlib. > --- > newlib/libc/machine/arm/setjmp.S | 16 ++++++++++++++++ > 1 file changed, 16 insertions(+) > > diff --git a/newlib/libc/machine/arm/setjmp.S b/newlib/libc/machine/arm/setjmp.S > index c615f2428..3a9aa840d 100644 > --- a/newlib/libc/machine/arm/setjmp.S > +++ b/newlib/libc/machine/arm/setjmp.S > @@ -64,6 +64,22 @@ > > .syntax unified > > +/* GCC 12.1 and later will tell the assembler exactly which floating > + point (or MVE) unit is required and we don't want to override > + that. Conversely, older versions of the compiler don't pass this > + information so we need to enable the VFP version that is most > + appropriate. The choice here should support all suitable VFP > + versions that the older toolchains can handle. */ > +#if __GNUC__ && __GNUC__ < 12 > +/* While GCC > 10.1 supports MVE, the MVE instructions do not need an > + .fpu directive, so we don't need to handle that case. VFPxd thus > + covers all the cases we need in this file and should be compatible > + with all required FPUs that we need to support. */ > +# if __ARM_FP > + .fpu vfpxd > +# endif > +#endif > + > #if __ARM_ARCH_ISA_THUMB == 1 && !__ARM_ARCH_ISA_ARM > /* ARMv6-M-like has to be implemented in Thumb mode. */ > Since MVE is available in GCC-10 onwards, I don't think that's quite enough. Compiling with -march=armv8.1-m.main+mve still needs the extension register set preserving during setjmp, but this will not cause __ARM_FP to be defined. So I think we need something like # if __ARM_FP .fpu vfpxd # endif # if __ARM_FEATURE_MVE .arch_extension mve # endif This should ensure that not only the files assemble correctly but they have suitable build attributes as well (otherwise we might get problems at link time if integer-only MVE code is linked with code claiming that full VFP is needed). R.