[PATCH] ARM64: Fix compiling with GCC 6 and Atomics enabled

[PATCH] ARM64: Fix compiling with GCC 6 and Atomics enabled

[Andrew Pinski]

The problem here is that GCC 6 and above emits .arch now
for each function so now the global .arch_extension has
no effect.  This fixes the problem by putting
.arch_extension inside ARM64_LSE_ATOMIC_INSN so
it is enabled for each place where LSE is used.

Signed-off-by: Andrew Pinski <apinski@cavium.com>
---
 arch/arm64/include/asm/lse.h |    4 +---
 1 files changed, 1 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/include/asm/lse.h b/arch/arm64/include/asm/lse.h
index 3de42d6..625601f 100644
--- a/arch/arm64/include/asm/lse.h
+++ b/arch/arm64/include/asm/lse.h
@@ -17,8 +17,6 @@
 
 #else	/* __ASSEMBLER__ */
 
-__asm__(".arch_extension	lse");
-
 /* Move the ll/sc atomics out-of-line */
 #define __LL_SC_INLINE
 #define __LL_SC_PREFIX(x)	__ll_sc_##x
@@ -29,7 +27,7 @@ __asm__(".arch_extension	lse");
 
 /* In-line patching at runtime */
 #define ARM64_LSE_ATOMIC_INSN(llsc, lse)				\
-	ALTERNATIVE(llsc, lse, ARM64_HAS_LSE_ATOMICS)
+	ALTERNATIVE(".arch_extension        lse\n" llsc, lse, ARM64_HAS_LSE_ATOMICS)
 
 #endif	/* __ASSEMBLER__ */
 #else	/* CONFIG_AS_LSE && CONFIG_ARM64_LSE_ATOMICS */
-- 
1.7.2.5

[PATCH] ARM64: Fix compiling with GCC 6 and Atomics enabled

[Will Deacon]

On Fri, Dec 18, 2015 at 08:17:35PM -0800, Andrew Pinski wrote:
> The problem here is that GCC 6 and above emits .arch now
> for each function so now the global .arch_extension has
> no effect.  This fixes the problem by putting
> .arch_extension inside ARM64_LSE_ATOMIC_INSN so
> it is enabled for each place where LSE is used.

Hmm, this is going to affect arch/arm/ much more heavily than arch/arm64.
.arch_extension is used for virt, mp and sec over there, and it may be
tricky to isolate the actual instruction usage (at least, virt looks
lost in kvm/arm.c).

Why can't gas have an option to accept all instruction encodings that it
knows about, inspite of any .arch directives?

Will

> Signed-off-by: Andrew Pinski <apinski@cavium.com>
> ---
>  arch/arm64/include/asm/lse.h |    4 +---
>  1 files changed, 1 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/lse.h b/arch/arm64/include/asm/lse.h
> index 3de42d6..625601f 100644
> --- a/arch/arm64/include/asm/lse.h
> +++ b/arch/arm64/include/asm/lse.h
> @@ -17,8 +17,6 @@
>  
>  #else	/* __ASSEMBLER__ */
>  
> -__asm__(".arch_extension	lse");
> -
>  /* Move the ll/sc atomics out-of-line */
>  #define __LL_SC_INLINE
>  #define __LL_SC_PREFIX(x)	__ll_sc_##x
> @@ -29,7 +27,7 @@ __asm__(".arch_extension	lse");
>  
>  /* In-line patching at runtime */
>  #define ARM64_LSE_ATOMIC_INSN(llsc, lse)				\
> -	ALTERNATIVE(llsc, lse, ARM64_HAS_LSE_ATOMICS)
> +	ALTERNATIVE(".arch_extension        lse\n" llsc, lse, ARM64_HAS_LSE_ATOMICS)
>  
>  #endif	/* __ASSEMBLER__ */
>  #else	/* CONFIG_AS_LSE && CONFIG_ARM64_LSE_ATOMICS */
> -- 
> 1.7.2.5
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 

[PATCH] ARM64: Fix compiling with GCC 6 and Atomics enabled

[Ard Biesheuvel]

On 21 December 2015 at 13:38, Will Deacon <will.deacon@arm.com> wrote:
> On Fri, Dec 18, 2015 at 08:17:35PM -0800, Andrew Pinski wrote:
>> The problem here is that GCC 6 and above emits .arch now
>> for each function so now the global .arch_extension has
>> no effect.  This fixes the problem by putting
>> .arch_extension inside ARM64_LSE_ATOMIC_INSN so
>> it is enabled for each place where LSE is used.
>
> Hmm, this is going to affect arch/arm/ much more heavily than arch/arm64.
> .arch_extension is used for virt, mp and sec over there, and it may be
> tricky to isolate the actual instruction usage (at least, virt looks
> lost in kvm/arm.c).
>
> Why can't gas have an option to accept all instruction encodings that it
> knows about, inspite of any .arch directives?
>

Modern GAS supports things like -march=armv7-a+mp+sec+virt, so it
probably makes sense to pass that on the command line when building
for v7 (or +sec only for v6) if the assembler is found to support it
at build time.


>> Signed-off-by: Andrew Pinski <apinski@cavium.com>
>> ---
>>  arch/arm64/include/asm/lse.h |    4 +---
>>  1 files changed, 1 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/arm64/include/asm/lse.h b/arch/arm64/include/asm/lse.h
>> index 3de42d6..625601f 100644
>> --- a/arch/arm64/include/asm/lse.h
>> +++ b/arch/arm64/include/asm/lse.h
>> @@ -17,8 +17,6 @@
>>
>>  #else        /* __ASSEMBLER__ */
>>
>> -__asm__(".arch_extension     lse");
>> -
>>  /* Move the ll/sc atomics out-of-line */
>>  #define __LL_SC_INLINE
>>  #define __LL_SC_PREFIX(x)    __ll_sc_##x
>> @@ -29,7 +27,7 @@ __asm__(".arch_extension    lse");
>>
>>  /* In-line patching at runtime */
>>  #define ARM64_LSE_ATOMIC_INSN(llsc, lse)                             \
>> -     ALTERNATIVE(llsc, lse, ARM64_HAS_LSE_ATOMICS)
>> +     ALTERNATIVE(".arch_extension        lse\n" llsc, lse, ARM64_HAS_LSE_ATOMICS)
>>
>>  #endif       /* __ASSEMBLER__ */
>>  #else        /* CONFIG_AS_LSE && CONFIG_ARM64_LSE_ATOMICS */
>> --
>> 1.7.2.5
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
>>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH] ARM64: Fix compiling with GCC 6 and Atomics enabled

[Will Deacon]

On Mon, Dec 21, 2015 at 01:46:22PM +0100, Ard Biesheuvel wrote:
> On 21 December 2015 at 13:38, Will Deacon <will.deacon@arm.com> wrote:
> > On Fri, Dec 18, 2015 at 08:17:35PM -0800, Andrew Pinski wrote:
> >> The problem here is that GCC 6 and above emits .arch now
> >> for each function so now the global .arch_extension has
> >> no effect.  This fixes the problem by putting
> >> .arch_extension inside ARM64_LSE_ATOMIC_INSN so
> >> it is enabled for each place where LSE is used.
> >
> > Hmm, this is going to affect arch/arm/ much more heavily than arch/arm64.
> > .arch_extension is used for virt, mp and sec over there, and it may be
> > tricky to isolate the actual instruction usage (at least, virt looks
> > lost in kvm/arm.c).
> >
> > Why can't gas have an option to accept all instruction encodings that it
> > knows about, inspite of any .arch directives?
> >
> 
> Modern GAS supports things like -march=armv7-a+mp+sec+virt, so it
> probably makes sense to pass that on the command line when building
> for v7 (or +sec only for v6) if the assembler is found to support it
> at build time.

Does that override a more restrictive .arch directive emitted by the
compiler?

Will

[PATCH] ARM64: Fix compiling with GCC 6 and Atomics enabled

[Ard Biesheuvel]

On 21 December 2015 at 13:51, Will Deacon <will.deacon@arm.com> wrote:
> On Mon, Dec 21, 2015 at 01:46:22PM +0100, Ard Biesheuvel wrote:
>> On 21 December 2015 at 13:38, Will Deacon <will.deacon@arm.com> wrote:
>> > On Fri, Dec 18, 2015 at 08:17:35PM -0800, Andrew Pinski wrote:
>> >> The problem here is that GCC 6 and above emits .arch now
>> >> for each function so now the global .arch_extension has
>> >> no effect.  This fixes the problem by putting
>> >> .arch_extension inside ARM64_LSE_ATOMIC_INSN so
>> >> it is enabled for each place where LSE is used.
>> >
>> > Hmm, this is going to affect arch/arm/ much more heavily than arch/arm64.
>> > .arch_extension is used for virt, mp and sec over there, and it may be
>> > tricky to isolate the actual instruction usage (at least, virt looks
>> > lost in kvm/arm.c).
>> >
>> > Why can't gas have an option to accept all instruction encodings that it
>> > knows about, inspite of any .arch directives?
>> >
>>
>> Modern GAS supports things like -march=armv7-a+mp+sec+virt, so it
>> probably makes sense to pass that on the command line when building
>> for v7 (or +sec only for v6) if the assembler is found to support it
>> at build time.
>
> Does that override a more restrictive .arch directive emitted by the
> compiler?
>

It seems to be additive: -march=armv7-a+mp+sec allows a .S file
containing a virt arch_extension + both hvc and smc instructions to be
assembled.

[PATCH] ARM64: Fix compiling with GCC 6 and Atomics enabled

[Will Deacon]

On Mon, Dec 21, 2015 at 01:58:30PM +0100, Ard Biesheuvel wrote:
> On 21 December 2015 at 13:51, Will Deacon <will.deacon@arm.com> wrote:
> > On Mon, Dec 21, 2015 at 01:46:22PM +0100, Ard Biesheuvel wrote:
> >> On 21 December 2015 at 13:38, Will Deacon <will.deacon@arm.com> wrote:
> >> > On Fri, Dec 18, 2015 at 08:17:35PM -0800, Andrew Pinski wrote:
> >> >> The problem here is that GCC 6 and above emits .arch now
> >> >> for each function so now the global .arch_extension has
> >> >> no effect.  This fixes the problem by putting
> >> >> .arch_extension inside ARM64_LSE_ATOMIC_INSN so
> >> >> it is enabled for each place where LSE is used.
> >> >
> >> > Hmm, this is going to affect arch/arm/ much more heavily than arch/arm64.
> >> > .arch_extension is used for virt, mp and sec over there, and it may be
> >> > tricky to isolate the actual instruction usage (at least, virt looks
> >> > lost in kvm/arm.c).
> >> >
> >> > Why can't gas have an option to accept all instruction encodings that it
> >> > knows about, inspite of any .arch directives?
> >> >
> >>
> >> Modern GAS supports things like -march=armv7-a+mp+sec+virt, so it
> >> probably makes sense to pass that on the command line when building
> >> for v7 (or +sec only for v6) if the assembler is found to support it
> >> at build time.
> >
> > Does that override a more restrictive .arch directive emitted by the
> > compiler?
> >
> 
> It seems to be additive: -march=armv7-a+mp+sec allows a .S file
> containing a virt arch_extension + both hvc and smc instructions to be
> assembled.

The problem I'm seeing is if I have something like:

  .arch_extension lse

before something like:

  .cpu cortex-a57+fp+simd+crc

-or-

  .arch armv8-a+fp+simd+crc

then I can no longer assemble lse instructions. So the .cpu/.arch
directive is undoing the .arch_extension. We can fix this by following
Andrew's suggestion to have .arch_extension before every point of use,
but the whole thing would be much simpler if we could just tell gas to
assemble harder.

Maybe we just need to construct the mother of all -march options based
on build-time checks in the Makefile?

Will

[PATCH] ARM64: Fix compiling with GCC 6 and Atomics enabled

[Vladimir Murzin]

On 21/12/15 13:37, Will Deacon wrote:
> On Mon, Dec 21, 2015 at 01:58:30PM +0100, Ard Biesheuvel wrote:
>> On 21 December 2015 at 13:51, Will Deacon <will.deacon@arm.com> wrote:
>>> On Mon, Dec 21, 2015 at 01:46:22PM +0100, Ard Biesheuvel wrote:
>>>> On 21 December 2015 at 13:38, Will Deacon <will.deacon@arm.com> wrote:
>>>>> On Fri, Dec 18, 2015 at 08:17:35PM -0800, Andrew Pinski wrote:
>>>>>> The problem here is that GCC 6 and above emits .arch now
>>>>>> for each function so now the global .arch_extension has
>>>>>> no effect.  This fixes the problem by putting
>>>>>> .arch_extension inside ARM64_LSE_ATOMIC_INSN so
>>>>>> it is enabled for each place where LSE is used.
>>>>>
>>>>> Hmm, this is going to affect arch/arm/ much more heavily than arch/arm64.
>>>>> .arch_extension is used for virt, mp and sec over there, and it may be
>>>>> tricky to isolate the actual instruction usage (at least, virt looks
>>>>> lost in kvm/arm.c).
>>>>>
>>>>> Why can't gas have an option to accept all instruction encodings that it
>>>>> knows about, inspite of any .arch directives?
>>>>>
>>>>
>>>> Modern GAS supports things like -march=armv7-a+mp+sec+virt, so it
>>>> probably makes sense to pass that on the command line when building
>>>> for v7 (or +sec only for v6) if the assembler is found to support it
>>>> at build time.
>>>
>>> Does that override a more restrictive .arch directive emitted by the
>>> compiler?
>>>
>>
>> It seems to be additive: -march=armv7-a+mp+sec allows a .S file
>> containing a virt arch_extension + both hvc and smc instructions to be
>> assembled.
> 
> The problem I'm seeing is if I have something like:
> 
>   .arch_extension lse
> 
> before something like:
> 
>   .cpu cortex-a57+fp+simd+crc
> 
> -or-
> 
>   .arch armv8-a+fp+simd+crc
> 
> then I can no longer assemble lse instructions. So the .cpu/.arch
> directive is undoing the .arch_extension. We can fix this by following
> Andrew's suggestion to have .arch_extension before every point of use,
> but the whole thing would be much simpler if we could just tell gas to
> assemble harder.
> 
> Maybe we just need to construct the mother of all -march options based
> on build-time checks in the Makefile?
> 

Since I've been bitten by this I'm curious what was conclusion on this
topic?

Thanks
Vladimir

> Will
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> 
> 
> 

[PATCH] ARM64: Fix compiling with GCC 6 and Atomics enabled

[Ard Biesheuvel]

On 21 January 2016 at 13:32, Vladimir Murzin <vladimir.murzin@arm.com> wrote:
> On 21/12/15 13:37, Will Deacon wrote:
>> On Mon, Dec 21, 2015 at 01:58:30PM +0100, Ard Biesheuvel wrote:
>>> On 21 December 2015 at 13:51, Will Deacon <will.deacon@arm.com> wrote:
>>>> On Mon, Dec 21, 2015 at 01:46:22PM +0100, Ard Biesheuvel wrote:
>>>>> On 21 December 2015 at 13:38, Will Deacon <will.deacon@arm.com> wrote:
>>>>>> On Fri, Dec 18, 2015 at 08:17:35PM -0800, Andrew Pinski wrote:
>>>>>>> The problem here is that GCC 6 and above emits .arch now
>>>>>>> for each function so now the global .arch_extension has
>>>>>>> no effect.  This fixes the problem by putting
>>>>>>> .arch_extension inside ARM64_LSE_ATOMIC_INSN so
>>>>>>> it is enabled for each place where LSE is used.
>>>>>>
>>>>>> Hmm, this is going to affect arch/arm/ much more heavily than arch/arm64.
>>>>>> .arch_extension is used for virt, mp and sec over there, and it may be
>>>>>> tricky to isolate the actual instruction usage (at least, virt looks
>>>>>> lost in kvm/arm.c).
>>>>>>
>>>>>> Why can't gas have an option to accept all instruction encodings that it
>>>>>> knows about, inspite of any .arch directives?
>>>>>>
>>>>>
>>>>> Modern GAS supports things like -march=armv7-a+mp+sec+virt, so it
>>>>> probably makes sense to pass that on the command line when building
>>>>> for v7 (or +sec only for v6) if the assembler is found to support it
>>>>> at build time.
>>>>
>>>> Does that override a more restrictive .arch directive emitted by the
>>>> compiler?
>>>>
>>>
>>> It seems to be additive: -march=armv7-a+mp+sec allows a .S file
>>> containing a virt arch_extension + both hvc and smc instructions to be
>>> assembled.
>>
>> The problem I'm seeing is if I have something like:
>>
>>   .arch_extension lse
>>
>> before something like:
>>
>>   .cpu cortex-a57+fp+simd+crc
>>
>> -or-
>>
>>   .arch armv8-a+fp+simd+crc
>>
>> then I can no longer assemble lse instructions. So the .cpu/.arch
>> directive is undoing the .arch_extension. We can fix this by following
>> Andrew's suggestion to have .arch_extension before every point of use,
>> but the whole thing would be much simpler if we could just tell gas to
>> assemble harder.
>>
>> Maybe we just need to construct the mother of all -march options based
>> on build-time checks in the Makefile?
>>
>
> Since I've been bitten by this I'm curious what was conclusion on this
> topic?
>

None that I'm aware of

[PATCH] ARM64: Fix compiling with GCC 6 and Atomics enabled

[Russell King - ARM Linux]

On Mon, Dec 21, 2015 at 01:46:22PM +0100, Ard Biesheuvel wrote:
> On 21 December 2015 at 13:38, Will Deacon <will.deacon@arm.com> wrote:
> > On Fri, Dec 18, 2015 at 08:17:35PM -0800, Andrew Pinski wrote:
> >> The problem here is that GCC 6 and above emits .arch now
> >> for each function so now the global .arch_extension has
> >> no effect.  This fixes the problem by putting
> >> .arch_extension inside ARM64_LSE_ATOMIC_INSN so
> >> it is enabled for each place where LSE is used.
> >
> > Hmm, this is going to affect arch/arm/ much more heavily than arch/arm64.
> > .arch_extension is used for virt, mp and sec over there, and it may be
> > tricky to isolate the actual instruction usage (at least, virt looks
> > lost in kvm/arm.c).
> >
> > Why can't gas have an option to accept all instruction encodings that it
> > knows about, inspite of any .arch directives?
> >
> 
> Modern GAS supports things like -march=armv7-a+mp+sec+virt, so it
> probably makes sense to pass that on the command line when building
> for v7 (or +sec only for v6) if the assembler is found to support it
> at build time.

Modern GCCs (GCC 4 at least) add .arch / .cpu pseudo-instructions in
the assembly output which means using -Wa,-march= and -Wa,-mcpu= to
GCC are now totally useless.

(From the bug reports I've seen, I don't deem GCC 5 to be anything but
a total failure, and so as far as I'm concerned, GCC 5 is not to be
used for ARM, and effectively doesn't exist.  I have no experience or
opinions on GCC 6.  Hence, "GCC 4" still counts as "modern" being the
only recent compilers that produce sane results.)

-- 
RMK's Patch system: http://www.arm.linux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.