[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