This is the mail archive of the
libc-ports@sources.redhat.com
mailing list for the libc-ports project.
Re: [PATCH] arm: Save and restore VFP arguments registers in PLT trampolines
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Meador Inge <meadori at codesourcery dot com>
- Cc: libc-ports at sourceware dot org
- Date: Thu, 19 Apr 2012 19:38:58 +0000 (UTC)
- Subject: Re: [PATCH] arm: Save and restore VFP arguments registers in PLT trampolines
- References: <1334190420-4385-1-git-send-email-meadori@codesourcery.com>
On Wed, 11 Apr 2012, Meador Inge wrote:
> +#if defined(__ARM_NEON__)
That's not the right condition.
The issue is not specific to NEON (__ARM_NEON__), or to the VFP AAPCS
variant (__ARM_PCS_VFP). It's easier to detect that there's a problem
when the VFP AAPCS variant is used, because then the issue can corrupt
function arguments. But the PLT may be used to call functions such as
__aeabi_memcpy whose ABIs are defined to clobber only registers that are
call-clobbered in the base AAPCS, not call-clobbered registers specific to
the VFP variant. So the issue applies to all call-clobbered VFP registers
regardless of the ABI. Furthermore, the VFP ABI variant can be used with
any version of VFP (including the single-precision-only versions, since
those still have double-precision moves), and does not need NEON (and I
made sure that GCC uses the same ABI for passing generic vectors when
using the VFP ABI variant for non-NEON VFP as it does for passing NEON
vector types with NEON enabled - these are fully compatible).
Of course the issue only applies if something in the dynamic linker
actually runs code, other than the function being called through the PLT,
that clobbers such registers. This can happen when the dynamic linker is
built with VFP enabled - it may be used internally by the compiler. There
may also be cases with audit modules; I'm not expert on those, but the
x86_64 dynamic linker has code to handle saving and restoring AVX
registers, based on dynamic detection of AVX (_dl_x86_64_restore_sse,
RTLD_ENABLE_FOREIGN_CALL, etc.).
Without regard to audit modules, the basic requirement is to save and
restore d0-d7 if available (defined (__VFP_FP__) && !defined
(__SOFTFP__)). And then d16-d31 must also be saved and restored if
available - but there isn't a preprocessor define for that. I don't know
how readily you can check HWCAPs (HWCAP_ARM_VFPv3, HWCAP_ARM_VFPv3D16)
here. Audit modules may require some dynamic detection in any case.
--
Joseph S. Myers
joseph@codesourcery.com