[PATCH] arm32: fix build after 063188f4b3

[PATCH] arm32: fix build after 063188f4b3

[Jan Beulich]

[-- Attachment #1: Type: text/plain, Size: 1601 bytes --]

"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@suse.com>

--- 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;
+
     asm volatile(
         __asmeq("%0", "r0")
         __asmeq("%1", "r1")
@@ -47,7 +52,7 @@ static noinline void exynos_smc(register
         __asmeq("%3", "r3")
         "smc #0"
         :
-        : "r" (function_id), "r" (arg0), "r" (arg1), "r" (arg2));
+        : "r" (fn_id), "r" (a0), "r" (a1), "r" (a2));
 }
 
 static int exynos5_init_time(void)




[-- Attachment #2: arm32-exynos5-smc.patch --]
[-- Type: text/plain, Size: 1632 bytes --]

arm32: fix build after 063188f4b3

"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@suse.com>

--- 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;
+
     asm volatile(
         __asmeq("%0", "r0")
         __asmeq("%1", "r1")
@@ -47,7 +52,7 @@ static noinline void exynos_smc(register
         __asmeq("%3", "r3")
         "smc #0"
         :
-        : "r" (function_id), "r" (arg0), "r" (arg1), "r" (arg2));
+        : "r" (fn_id), "r" (a0), "r" (a1), "r" (a2));
 }
 
 static int exynos5_init_time(void)

[-- Attachment #3: Type: text/plain, Size: 126 bytes --]

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

Re: [PATCH] arm32: fix build after 063188f4b3

[Julien Grall]

Hi Jan,

On 10/10/2014 14:58, 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.

I'm not sure to understand here. If the function is marked as noinlined, 
that would mean the arguments will be passed with the ARM in the 
register with the ARM calling convention (i.e r0 for argument 0...). Why 
GCC would try to create a clone of this function?

> The alternative of adding __attribute__((optimize("-fno-ipa-cp")))
> to the function definition would likely not work with all supported
> compiler versions.

The function was first introduced in arch/arm/psci.c (it's a copy of the 
Linux one in arch/arm/kernel/psci.c).

Does it mean that Linux code is buggy too?

> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>
> --- 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;
> +
>       asm volatile(
>           __asmeq("%0", "r0")
>           __asmeq("%1", "r1")
> @@ -47,7 +52,7 @@ static noinline void exynos_smc(register
>           __asmeq("%3", "r3")
>           "smc #0"
>           :
> -        : "r" (function_id), "r" (arg0), "r" (arg1), "r" (arg2));
> +        : "r" (fn_id), "r" (a0), "r" (a1), "r" (a2));
>   }

This function is duplicate in 3 different places in Xen:
	- arch/arm/psci.c
	- arch/platforms/exynos5.c
	- arch/platforms/seattle.c

So all those functions should be fixed. I think it's time to introduce a 
global SMC function...

Regards,

-- 
Julien Grall

Re: [PATCH] arm32: fix build after 063188f4b3

[Ian Campbell]

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@suse.com>
> 
> --- 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 suppose you have a compiler which tickles this?

Ian.

Re: [PATCH] arm32: fix build after 063188f4b3

[Stefano Stabellini]

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@suse.com>
> > 
> > --- 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.

Re: [PATCH] arm32: fix build after 063188f4b3

[Jan Beulich]

>>> On 10.10.14 at 16:12, <julien.grall@linaro.org> wrote:
> On 10/10/2014 14:58, 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.
> 
> I'm not sure to understand here. If the function is marked as noinlined, 
> that would mean the arguments will be passed with the ARM in the 
> register with the ARM calling convention (i.e r0 for argument 0...). Why 
> GCC would try to create a clone of this function?

The compiler is free to do so as long as the language specification isn't
being violated.

>> The alternative of adding __attribute__((optimize("-fno-ipa-cp")))
>> to the function definition would likely not work with all supported
>> compiler versions.
> 
> The function was first introduced in arch/arm/psci.c (it's a copy of the 
> Linux one in arch/arm/kernel/psci.c).
> 
> Does it mean that Linux code is buggy too?

Likely.

> This function is duplicate in 3 different places in Xen:
> 	- arch/arm/psci.c
> 	- arch/platforms/exynos5.c
> 	- arch/platforms/seattle.c
> 
> So all those functions should be fixed. I think it's time to introduce a 
> global SMC function...

Okay, I got the build failure only in this one place. But if and when
the compiler choses to do such transformations is entirely up to it,
so yes, if there are multiple instances likely they all would need
fixing.

Jan

Re: [PATCH] arm32: fix build after 063188f4b3

[Jan Beulich]

>>> On 10.10.14 at 16:17, <Ian.Campbell@eu.citrix.com> wrote:
> On Fri, 2014-10-10 at 14:58 +0100, Jan Beulich wrote:
>>  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.

It is formally documented to play by this, so I don't think this is
x86 specific, and I would strongly suspect any (apparent) violation
of this to be either a misunderstanding of the guarantees that are
being made or a bug in the specific compiler version.

> Stefano may remember better (since this was in the context of the Linux
> hypervisor stub).
> 
> I suppose you have a compiler which tickles this?

Yes, the gcc 4.9.1 I use for testing the ARM builds.

Jan

Re: [PATCH] arm32: fix build after 063188f4b3

[Jan Beulich]

>>> On 10.10.14 at 16:32, <stefano.stabellini@eu.citrix.com> wrote:
> I would appreciate if Jan could post the assembly he is getting.

Here you go:

	.type	exynos_smc.constprop.1, %function
exynos_smc.constprop.1:
.LFB277:
	.loc 1 40 0
	.cfi_startproc
	@ args = 0, pretend = 0, frame = 0
	@ frame_needed = 0, uses_anonymous_args = 0
	@ link register save eliminated.
.LVL52:
	.loc 1 43 0
	mvn	r2, #3
	mov	r3, #0
#APP
@ 43 "exynos5.c" 1
	.ifnc r2,r0 ; .err ; .endif
	.ifnc r0,r1 ; .err ; .endif
	.ifnc r3,r2 ; .err ; .endif
	.ifnc r3,r3 ; .err ; .endif
	smc #0
@ 0 "" 2
	.loc 1 51 0
	bx	lr
	.cfi_endproc
.LFE277:
	.size	exynos_smc.constprop.1, .-exynos_smc.constprop.1

with this call site code

	mov	r0, r6
	bl	exynos_smc.constprop.1

Jan

Re: [PATCH] arm32: fix build after 063188f4b3

[Ian Campbell]

On Fri, 2014-10-10 at 15:54 +0100, Jan Beulich wrote:
> >>> On 10.10.14 at 16:17, <Ian.Campbell@eu.citrix.com> wrote:
> > On Fri, 2014-10-10 at 14:58 +0100, Jan Beulich wrote:
> >>  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.
> 
> It is formally documented to play by this,

You made me look again and here it is
https://gcc.gnu.org/onlinedocs/gcc/Local-Reg-Vars.html

>  so I don't think this is
> x86 specific, and I would strongly suspect any (apparent) violation
> of this to be either a misunderstanding of the guarantees that are
> being made or a bug in the specific compiler version.

I may well be misremembering the older discussions...

Either way, you retained the asmeq bits so even if there are broken
gcc's out there we won't produce broken binaries and your patch is a
clear improvement IMHO.

> > Stefano may remember better (since this was in the context of the Linux
> > hypervisor stub).
> > 
> > I suppose you have a compiler which tickles this?
> 
> Yes, the gcc 4.9.1 I use for testing the ARM builds.

I'm still on 4.8, I'll grab a 4.9 and use it occasionally...

Ian.

Re: [PATCH] arm32: fix build after 063188f4b3

[Julien Grall]

Hi Jan,

On 10/10/2014 15:51, Jan Beulich wrote:
>>>> On 10.10.14 at 16:12, <julien.grall@linaro.org> wrote:
>> On 10/10/2014 14:58, 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.
>>
>> I'm not sure to understand here. If the function is marked as noinlined,
>> that would mean the arguments will be passed with the ARM in the
>> register with the ARM calling convention (i.e r0 for argument 0...). Why
>> GCC would try to create a clone of this function?
>
> The compiler is free to do so as long as the language specification isn't
> being violated.

Thanks for the explanation.

>>> The alternative of adding __attribute__((optimize("-fno-ipa-cp")))
>>> to the function definition would likely not work with all supported
>>> compiler versions.
>>
>> The function was first introduced in arch/arm/psci.c (it's a copy of the
>> Linux one in arch/arm/kernel/psci.c).
>>
>> Does it mean that Linux code is buggy too?
>
> Likely.
>
>> This function is duplicate in 3 different places in Xen:
>> 	- arch/arm/psci.c
>> 	- arch/platforms/exynos5.c
>> 	- arch/platforms/seattle.c
>>
>> So all those functions should be fixed. I think it's time to introduce a
>> global SMC function...
>
> Okay, I got the build failure only in this one place. But if and when
> the compiler choses to do such transformations is entirely up to it,
> so yes, if there are multiple instances likely they all would need
> fixing.

BTW,  named register is a GNU extension and not supported by clang. Can 
you avoid to use them? Maybe by writing the function in assembly. So we 
are safe against any compiler optimization.

Regards,

-- 
Julien Grall

Re: [PATCH] arm32: fix build after 063188f4b3

[Ian Campbell]

On Fri, 2014-10-10 at 16:55 +0100, Julien Grall wrote:
> Hi Jan,
> 
> On 10/10/2014 15:51, Jan Beulich wrote:
> >>>> On 10.10.14 at 16:12, <julien.grall@linaro.org> wrote:
> >> On 10/10/2014 14:58, 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.
> >>
> >> I'm not sure to understand here. If the function is marked as noinlined,
> >> that would mean the arguments will be passed with the ARM in the
> >> register with the ARM calling convention (i.e r0 for argument 0...). Why
> >> GCC would try to create a clone of this function?
> >
> > The compiler is free to do so as long as the language specification isn't
> > being violated.
> 
> Thanks for the explanation.
> 
> >>> The alternative of adding __attribute__((optimize("-fno-ipa-cp")))
> >>> to the function definition would likely not work with all supported
> >>> compiler versions.
> >>
> >> The function was first introduced in arch/arm/psci.c (it's a copy of the
> >> Linux one in arch/arm/kernel/psci.c).
> >>
> >> Does it mean that Linux code is buggy too?
> >
> > Likely.
> >
> >> This function is duplicate in 3 different places in Xen:
> >> 	- arch/arm/psci.c
> >> 	- arch/platforms/exynos5.c
> >> 	- arch/platforms/seattle.c
> >>
> >> So all those functions should be fixed. I think it's time to introduce a
> >> global SMC function...
> >
> > Okay, I got the build failure only in this one place. But if and when
> > the compiler choses to do such transformations is entirely up to it,
> > so yes, if there are multiple instances likely they all would need
> > fixing.
> 
> BTW,  named register is a GNU extension and not supported by clang. Can 
> you avoid to use them? Maybe by writing the function in assembly. So we 
> are safe against any compiler optimization.

I think Jan's patch (or something like it either applied to all three
sites or a new consolidated single site) is good enough for now, given
we are in a freeze.

If you want to rewrite in asm to support clang then that can be done as
a follow up.
ian

Re: [PATCH] arm32: fix build after 063188f4b3

[Julien Grall]

On 10/10/2014 17:01, Ian Campbell wrote:
> On Fri, 2014-10-10 at 16:55 +0100, Julien Grall wrote:
>> Hi Jan,
>>
>> On 10/10/2014 15:51, Jan Beulich wrote:
>>>>>> On 10.10.14 at 16:12, <julien.grall@linaro.org> wrote:
>>>> On 10/10/2014 14:58, 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.
>>>>
>>>> I'm not sure to understand here. If the function is marked as noinlined,
>>>> that would mean the arguments will be passed with the ARM in the
>>>> register with the ARM calling convention (i.e r0 for argument 0...). Why
>>>> GCC would try to create a clone of this function?
>>>
>>> The compiler is free to do so as long as the language specification isn't
>>> being violated.
>>
>> Thanks for the explanation.
>>
>>>>> The alternative of adding __attribute__((optimize("-fno-ipa-cp")))
>>>>> to the function definition would likely not work with all supported
>>>>> compiler versions.
>>>>
>>>> The function was first introduced in arch/arm/psci.c (it's a copy of the
>>>> Linux one in arch/arm/kernel/psci.c).
>>>>
>>>> Does it mean that Linux code is buggy too?
>>>
>>> Likely.
>>>
>>>> This function is duplicate in 3 different places in Xen:
>>>> 	- arch/arm/psci.c
>>>> 	- arch/platforms/exynos5.c
>>>> 	- arch/platforms/seattle.c
>>>>
>>>> So all those functions should be fixed. I think it's time to introduce a
>>>> global SMC function...
>>>
>>> Okay, I got the build failure only in this one place. But if and when
>>> the compiler choses to do such transformations is entirely up to it,
>>> so yes, if there are multiple instances likely they all would need
>>> fixing.
>>
>> BTW,  named register is a GNU extension and not supported by clang. Can
>> you avoid to use them? Maybe by writing the function in assembly. So we
>> are safe against any compiler optimization.
>
> I think Jan's patch (or something like it either applied to all three
> sites or a new consolidated single site) is good enough for now, given
> we are in a freeze.
>
> If you want to rewrite in asm to support clang then that can be done as
> a follow up.

I find pointless to do a follow-up later if we decide to go to a 
consolidated single site.

The freeze period doesn't mean we need to do something that we know 
won't work on different compiler. Mainly when it will take the same time 
to write the code (~2 lines of assembly).

I'm fine to write those 2 lines of assembly if this is a matter of lake 
of time.

Regards,

-- 
Julien Grall

Re: [PATCH] arm32: fix build after 063188f4b3

[Jan Beulich]

>>> On 10.10.14 at 17:55, <julien.grall@linaro.org> wrote:
> On 10/10/2014 15:51, Jan Beulich wrote:
>>>>> On 10.10.14 at 16:12, <julien.grall@linaro.org> wrote:
>>> This function is duplicate in 3 different places in Xen:
>>> 	- arch/arm/psci.c
>>> 	- arch/platforms/exynos5.c
>>> 	- arch/platforms/seattle.c
>>>
>>> So all those functions should be fixed. I think it's time to introduce a
>>> global SMC function...
>>
>> Okay, I got the build failure only in this one place. But if and when
>> the compiler choses to do such transformations is entirely up to it,
>> so yes, if there are multiple instances likely they all would need
>> fixing.
> 
> BTW,  named register is a GNU extension and not supported by clang. Can 
> you avoid to use them? Maybe by writing the function in assembly. So we 
> are safe against any compiler optimization.

I don't think I'm the right one to write ARM assembly code at this
point. I really just want the build fixed - anything beyond that I'd
rather leave to you guys.

Jan

Re: [PATCH] arm32: fix build after 063188f4b3

[Ian Campbell]

On Fri, 2014-10-10 at 17:14 +0100, Julien Grall wrote:

> I'm fine to write those 2 lines of assembly if this is a matter of lake 
> of time.

Please do.

Re: [PATCH] arm32: fix build after 063188f4b3

[Julien Grall]

On 10/10/2014 17:18, Jan Beulich wrote:
>>>> On 10.10.14 at 17:55, <julien.grall@linaro.org> wrote:
>> On 10/10/2014 15:51, Jan Beulich wrote:
>>>>>> On 10.10.14 at 16:12, <julien.grall@linaro.org> wrote:
>>>> This function is duplicate in 3 different places in Xen:
>>>> 	- arch/arm/psci.c
>>>> 	- arch/platforms/exynos5.c
>>>> 	- arch/platforms/seattle.c
>>>>
>>>> So all those functions should be fixed. I think it's time to introduce a
>>>> global SMC function...
>>>
>>> Okay, I got the build failure only in this one place. But if and when
>>> the compiler choses to do such transformations is entirely up to it,
>>> so yes, if there are multiple instances likely they all would need
>>> fixing.
>>
>> BTW,  named register is a GNU extension and not supported by clang. Can
>> you avoid to use them? Maybe by writing the function in assembly. So we
>> are safe against any compiler optimization.
>
> I don't think I'm the right one to write ARM assembly code at this
> point. I really just want the build fixed - anything beyond that I'd
> rather leave to you guys.

I will write a patch and send it during the week-end.

Regards,

-- 
Julien Grall

Re: [PATCH] arm32: fix build after 063188f4b3

[Ian Campbell]

On Fri, 2014-10-10 at 17:14 +0100, Julien Grall wrote:
> The freeze period doesn't mean we need to do something that we know 
> won't work on different compiler.

Conversely we shouldn't block a fix for a known regression because it
doesn't work with clang, which AFAIK can't currently build Xen anyway.

Nor should we put the burden of supporting clang on Jan.

Ian.

Re: [PATCH] arm32: fix build after 063188f4b3

[Stefano Stabellini]

On Fri, 10 Oct 2014, Jan Beulich wrote:
> >>> On 10.10.14 at 16:32, <stefano.stabellini@eu.citrix.com> wrote:
> > I would appreciate if Jan could post the assembly he is getting.
> 
> Here you go:
> 
> 	.type	exynos_smc.constprop.1, %function
> exynos_smc.constprop.1:
> .LFB277:
> 	.loc 1 40 0
> 	.cfi_startproc
> 	@ args = 0, pretend = 0, frame = 0
> 	@ frame_needed = 0, uses_anonymous_args = 0
> 	@ link register save eliminated.
> .LVL52:
> 	.loc 1 43 0
> 	mvn	r2, #3
> 	mov	r3, #0

That cannot be right: ~3 ends up in r2, while r2 should be 0.
This doesn't look like an optimization: it looks like a bug.
Am I missing something?


> #APP
> @ 43 "exynos5.c" 1
> 	.ifnc r2,r0 ; .err ; .endif
> 	.ifnc r0,r1 ; .err ; .endif
> 	.ifnc r3,r2 ; .err ; .endif
> 	.ifnc r3,r3 ; .err ; .endif
> 	smc #0
> @ 0 "" 2
> 	.loc 1 51 0
> 	bx	lr
> 	.cfi_endproc
> .LFE277:
> 	.size	exynos_smc.constprop.1, .-exynos_smc.constprop.1
> 
> with this call site code
> 
> 	mov	r0, r6
> 	bl	exynos_smc.constprop.1
> 
> Jan
> 

Re: [PATCH] arm32: fix build after 063188f4b3

[Jan Beulich]

>>> On 10.10.14 at 19:03, <stefano.stabellini@eu.citrix.com> wrote:
> On Fri, 10 Oct 2014, Jan Beulich wrote:
>> >>> On 10.10.14 at 16:32, <stefano.stabellini@eu.citrix.com> wrote:
>> > I would appreciate if Jan could post the assembly he is getting.
>> 
>> Here you go:
>> 
>> 	.type	exynos_smc.constprop.1, %function
>> exynos_smc.constprop.1:
>> .LFB277:
>> 	.loc 1 40 0
>> 	.cfi_startproc
>> 	@ args = 0, pretend = 0, frame = 0
>> 	@ frame_needed = 0, uses_anonymous_args = 0
>> 	@ link register save eliminated.
>> .LVL52:
>> 	.loc 1 43 0
>> 	mvn	r2, #3
>> 	mov	r3, #0
> 
> That cannot be right: ~3 ends up in r2, while r2 should be 0.
> This doesn't look like an optimization: it looks like a bug.
> Am I missing something?

Yes - the asm() doesn't enforce the specific registers (and it can't
due to the lack of suitable constraints), and hence the compiler
is permitted to use other than the registers checked for in the
subsequent .if-s. It is the purpose of this patch to address this.

Jan

Re: [PATCH] arm32: fix build after 063188f4b3

[Stefano Stabellini]

On Mon, 13 Oct 2014, Jan Beulich wrote:
> >>> On 10.10.14 at 19:03, <stefano.stabellini@eu.citrix.com> wrote:
> > On Fri, 10 Oct 2014, Jan Beulich wrote:
> >> >>> On 10.10.14 at 16:32, <stefano.stabellini@eu.citrix.com> wrote:
> >> > I would appreciate if Jan could post the assembly he is getting.
> >> 
> >> Here you go:
> >> 
> >> 	.type	exynos_smc.constprop.1, %function
> >> exynos_smc.constprop.1:
> >> .LFB277:
> >> 	.loc 1 40 0
> >> 	.cfi_startproc
> >> 	@ args = 0, pretend = 0, frame = 0
> >> 	@ frame_needed = 0, uses_anonymous_args = 0
> >> 	@ link register save eliminated.
> >> .LVL52:
> >> 	.loc 1 43 0
> >> 	mvn	r2, #3
> >> 	mov	r3, #0
> > 
> > That cannot be right: ~3 ends up in r2, while r2 should be 0.
> > This doesn't look like an optimization: it looks like a bug.
> > Am I missing something?
> 
> Yes - the asm() doesn't enforce the specific registers (and it can't
> due to the lack of suitable constraints), and hence the compiler
> is permitted to use other than the registers checked for in the
> subsequent .if-s. It is the purpose of this patch to address this.

Is ipa-cp allowed to break the ABI?
I thought it was not, maybe it is.

Because in this case gcc is not upholding the definition of noinline: it
is not respecting the calling convention. r2 should be set to 0 and r1
should be set to "cpu" before branching to exynos_smc.constprop.1.
Inside exynos_smc.constprop.1 gcc can do whatever it wants (even though
I fail to see why gcc wants to assign ~3 to r2 before smc).

I could understand if gcc was assigning the constant function arguments
right after the call, instead of before the call, but it is not what it
is doing here, or it is doing it incorrectly.

Re: [PATCH] arm32: fix build after 063188f4b3

[Jan Beulich]

>>> On 13.10.14 at 11:40, <stefano.stabellini@eu.citrix.com> wrote:
> On Mon, 13 Oct 2014, Jan Beulich wrote:
>> >>> On 10.10.14 at 19:03, <stefano.stabellini@eu.citrix.com> wrote:
>> > On Fri, 10 Oct 2014, Jan Beulich wrote:
>> >> >>> On 10.10.14 at 16:32, <stefano.stabellini@eu.citrix.com> wrote:
>> >> > I would appreciate if Jan could post the assembly he is getting.
>> >> 
>> >> Here you go:
>> >> 
>> >> 	.type	exynos_smc.constprop.1, %function
>> >> exynos_smc.constprop.1:
>> >> .LFB277:
>> >> 	.loc 1 40 0
>> >> 	.cfi_startproc
>> >> 	@ args = 0, pretend = 0, frame = 0
>> >> 	@ frame_needed = 0, uses_anonymous_args = 0
>> >> 	@ link register save eliminated.
>> >> .LVL52:
>> >> 	.loc 1 43 0
>> >> 	mvn	r2, #3
>> >> 	mov	r3, #0
>> > 
>> > That cannot be right: ~3 ends up in r2, while r2 should be 0.
>> > This doesn't look like an optimization: it looks like a bug.
>> > Am I missing something?
>> 
>> Yes - the asm() doesn't enforce the specific registers (and it can't
>> due to the lack of suitable constraints), and hence the compiler
>> is permitted to use other than the registers checked for in the
>> subsequent .if-s. It is the purpose of this patch to address this.
> 
> Is ipa-cp allowed to break the ABI?

It is not breaking any ABI - the ABI describes only the calling
convention between global functions. Yet here we're talking
about a static one.

And even for global functions it could, apart from creating an
instance with the "normal" name and following the ABI, create
any number of (local) clones with altered argument/parameter
mappings.

> I thought it was not, maybe it is.
> 
> Because in this case gcc is not upholding the definition of noinline: it
> is not respecting the calling convention. r2 should be set to 0 and r1
> should be set to "cpu" before branching to exynos_smc.constprop.1.
> Inside exynos_smc.constprop.1 gcc can do whatever it wants (even though
> I fail to see why gcc wants to assign ~3 to r2 before smc).
> 
> I could understand if gcc was assigning the constant function arguments
> right after the call, instead of before the call, but it is not what it
> is doing here, or it is doing it incorrectly.

No, it is doing exactly what it was asked to do: Pass four inputs (out
of which two have known identical values) to the asm() in _any_
general registers.

Jan