Re: [Xen-devel] [PATCH] arm32: fix build after 063188f4b3

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Fri, 10 Oct 2014, Ian Campbell wrote:
> On Fri, 2014-10-10 at 14:58 +0100, Jan Beulich wrote:
> > "xen: arm: Add support for the Exynos secure firmware" introduced code
> > assuming that exynos_smc() would get called with arguments in certain
> > registers. While the "noinline" attribute guarantees the function to
> > not get inlined, it does not guarantee that all arguments arrive in the
> > assumed registers: gcc's interprocedural analysis can result in clone
> > functions to be created where some of the incoming arguments (commonly
> > when they have constant values) get replaced by putting in place the
> > respective values inside the clone.
> > 
> > The alternative of adding __attribute__((optimize("-fno-ipa-cp")))
> > to the function definition would likely not work with all supported
> > compiler versions.
> > 
> > Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> > 
> > --- a/xen/arch/arm/platforms/exynos5.c
> > +++ b/xen/arch/arm/platforms/exynos5.c
> > @@ -40,6 +40,11 @@ static bool_t secure_firmware;
> >  static noinline void exynos_smc(register_t function_id, register_t arg0,
> >                                  register_t arg1, register_t arg2)
> >  {
> > +    register register_t fn_id asm("r0") = function_id;
> > +    register register_t a0 asm("r1") = arg0;
> > +    register register_t a1 asm("r2") = arg1;
> > +    register register_t a2 asm("r3") = arg2;
> 
> ISTR being told that the arm gcc backend pays this sort of asm("r1")
> thing no heed (it's x86 specific?). This is how we ended up with the
> asmeq -- it was what the arm compiler guys (via the arm kernels guys)
> recommended.
> 
> Stefano may remember better (since this was in the context of the Linux
> hypervisor stub).

I think that ensures that the compiler doesn't move stuff around in the
registers between the function call and the asm volatile.  But what if
one of the registers is missing entirely from the function call because
it has been optimized away as constant?

Look at the description of ipa-cp: it seems that all it takes is a
caller passing a constant as parameter and gcc might feel entitled to
"optimize the function".

If that is the case, then Linux is susceptible to this problem too and I
think it would be best to implement a generic smc call function in
assembly.


> I suppose you have a compiler which tickles this?

I would appreciate if Jan could post the assembly he is getting.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel