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

[Adhemerval Zanella Netto]

On 12/05/26 17:54, Joseph Myers wrote:
> On Tue, 12 May 2026, Adhemerval Zanella Netto wrote:
> 
>> 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.
> 
> But there are also the cases (relevant for call-clobbered VFP registers in 
> general as discussed below, not for argument passing using such registers) 
> of:
> 
> * Soft-float ABI (rather than VFP PCS variant), but with VFP enabled, so 
> VFP might be used inside glibc.
> 
> * Soft-float build, but IFUNC resolvers / audit modules / interposed 
> malloc are user code built with VFP (soft-float ABI) and executed from 
> within symbol resolution.

Indeed, and I complete forgot the armv7 ifunc variants.

> 
>> 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 noted in bug 15792 that all call-clobbered VFP registers need to be 
> preserved because of the requirements (in RTABI32) that __aeabi_mem* 
> functions, that may be called via the dynamic linker, only corrupt integer 
> core registers.
> 

I should have read your bug report more closely.  We will need to always
save the registers depending of the underlying hardware support instead of
the ABI then.