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
On 04/11/2012 08:11 PM, Carlos O'Donell wrote:
> On Wed, Apr 11, 2012 at 8:27 PM, Meador Inge <meadori@codesourcery.com> wrote:
>> This patch fixes an issue in '_dl_runtime_resolve' and '_dl_runtime_profile'
>> where the VFP argument registers are not properly saved and restored around
>> '_dl_fixup'.
>>
>> OK?
>>
>> Signed-off-by: Meador Inge <meadori@codesourcery.com>
>>
>> 2012-04-11 Meador Inge <meadori@codesourcery.com>
>>
>> * sysdeps/arm/dl-trampoline.S (_dl_runtime_resolve): Save and
>> restore VFP argument registers.
>> (_dl_runtime_profile): Likewise.
>
> Why do they need to be saved/restored?
>
> Are VFP registers caller saves?
Per the AAPCS d0-d7 are used for passing floating-point parameters.
The same way we save and restore r0-r3 we must save and restore d0-d7
when building for __ARM_NEON__.
> Is it because we are *about* to call the real function, but instead
> control is transferred to the lazy resolution code which might itself
> use VFP registers and clobber the existing values in the VFP registers
> that were intended for the eventually resolved function?
Exactly.
> If this is the case... then how did this ever work in the past? Were we lucky?
I guess so. It is tricky to reproduce. Joseph created a fairly complicated
test case that I used to analyze the behavior.
--
Meador Inge
CodeSourcery / Mentor Embedded
http://www.mentor.com/embedded-software