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: "Carlos O'Donell" <carlos at systemhalted dot org>
- To: Meador Inge <meadori at codesourcery dot com>
- Cc: libc-ports at sourceware dot org
- Date: Wed, 11 Apr 2012 21:11:25 -0400
- 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, 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?
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?
If this is the case... then how did this ever work in the past? Were we lucky?
Cheers,
Carlos.