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

Joseph Myers josmyers@redhat.com
Tue May 12 20:54:08 GMT 2026


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.

> 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.

-- 
Joseph S. Myers
josmyers@redhat.com


More information about the Libc-alpha mailing list