This is the mail archive of the libc-ports@sources.redhat.com mailing list for the libc-ports project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]