[PATCH] arm: Prevent GCC from using VFP registers in code used during dynamic linking

[Adhemerval Zanella Netto]

On 12/05/26 16:20, Joseph Myers wrote:
> On Tue, 12 May 2026, Aurelien Jarno wrote:
> 
>> - glibc (or rather ld.so) is built without VFP support. In that case 
>>   there is no need to save and restore VFP registers, as they are not 
>>   clobbered.
> 
> All the usual reasons apply for user code possibly being run during symbol 
> resolution that might clobber those registers.
> 
>> Therefore I think there is just a need to test support at build time. I 
>> guess checking for HAVE_ARM_PCS_VFP and HAVE_ARM_PCS_VFP_D32 is enough.
> 
> Whether VFP is used at build time is separate from whether the VFP AAPCS 
> variant is used.
> 

Indeed, but double checking I think the runtime HWCAP checks are indeed
unnecessary.  For _dl_runtime_resolve the situation is:

* hardfp build (HAVE_ARM_PCS_VFP defined): the program cannot run on hardware
  without VFP — the ABI itself depends on it. HWCAP_ARM_VFP is always set and
  the runtime test is dead code.

* Softfp build (__SOFTFP__ defined): no VFP instruction is ever emitted in
  glibc/ld.so, so _dl_fixup cannot clobber any VFP register.  Saving them is
  pointless even if the hardware has them.

So HAVE_ARM_PCS_VFP (build-time) replaces the HWCAP_ARM_VFP runtime check
cleanly.

And different than _dl_tlsdesc_dynamic, there is not need to save d8–d31 at all
because _dl_runtime_resolve is called fallowing the usual AAPCS-VFP ABI. 

I forgot that _dl_tlsdesc_dynamic have different constraints. Let me prepare a
patch.