Re: [PATCH 1/3] x86/hash: fix build failure with older binutils
On 02/23/2014 11:56 PM, Jan Beulich wrote: 2.17 doesn't have support for it either, yet has support for fxsaveq (which you can see in the patch context we check for too). Apart from that Documentation/Changes continues to state binutils 2.12 to be the minimum requirement... Documentation/Changes (maybe) reflects the minimums across all architectures, which really has never applied to any single architecture for a long time. x86 requires gcc 3.4 at a minimum, for example, and it is not clear that that is sufficient anymore, either. We don't really have good documentation about what the requirements for various specific arches are... That being said, it sounds like this one is justified. -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] x86/hash: fix build failure with older binutils
>>> On 21.02.14 at 20:17, "H. Peter Anvin" wrote: > On 02/21/2014 06:16 AM, Jan Beulich wrote: > On 21.02.14 at 13:51, "H. Peter Anvin" wrote: >>> How old? >> >> 2.16.91.0.5 (SLE10) >> > > I would *love* to kill off binutils 2.16. It was a horribly buggy > version, and it has been hard to deal with keeping things alive with it. > How important is this? > > Since this is the first I've heard of this being broken, I am kind of > encouraged that maybe we can move on? 2.17 doesn't have support for it either, yet has support for fxsaveq (which you can see in the patch context we check for too). Apart from that Documentation/Changes continues to state binutils 2.12 to be the minimum requirement... Jan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] x86/hash: fix build failure with older binutils
On 02/21/2014 06:16 AM, Jan Beulich wrote: On 21.02.14 at 13:51, "H. Peter Anvin" wrote: >> How old? > > 2.16.91.0.5 (SLE10) > I would *love* to kill off binutils 2.16. It was a horribly buggy version, and it has been hard to deal with keeping things alive with it. How important is this? Since this is the first I've heard of this being broken, I am kind of encouraged that maybe we can move on? -hpa -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] x86/hash: fix build failure with older binutils
>>> On 21.02.14 at 13:51, "H. Peter Anvin" wrote:
> How old?
2.16.91.0.5 (SLE10)
Jan
> On February 21, 2014 2:32:50 AM PST, Jan Beulich wrote:
>>Just like for other ISA extension instruction uses we should check
>>whether the assembler actually supports them. The fallback here simply
>>is to encode an instruction with fixed operands (%eax and %ecx).
>>
>>Signed-off-by: Jan Beulich
>>Cc: Francesco Fusco
>>Cc: Daniel Borkmann
>>Cc: Thomas Graf
>>Cc: David S. Miller
>>---
>> arch/x86/Makefile |1 +
>> arch/x86/lib/hash.c |4
>> 2 files changed, 5 insertions(+)
>>
>>--- 3.14-rc3-x86-hash-crc32.orig/arch/x86/Makefile
>>+++ 3.14-rc3-x86-hash-crc32/arch/x86/Makefile
>>@@ -152,6 +152,7 @@ cfi-sections := $(call as-instr,.cfi_sec
>>
>> # does binutils support specific instructions?
>> asinstr := $(call as-instr,fxsaveq (%rax),-DCONFIG_AS_FXSAVEQ=1)
>>+asinstr += $(call as-instr,crc32l
>>%eax$(comma)%eax,-DCONFIG_AS_CRC32=1)
>>avx_instr := $(call as-instr,vxorps
>>%ymm0$(comma)%ymm1$(comma)%ymm2,-DCONFIG_AS_AVX=1)
>>avx2_instr :=$(call as-instr,vpbroadcastb
>>%xmm0$(comma)%ymm1,-DCONFIG_AS_AVX2=1)
>>
>>--- 3.14-rc3-x86-hash-crc32.orig/arch/x86/lib/hash.c
>>+++ 3.14-rc3-x86-hash-crc32/arch/x86/lib/hash.c
>>@@ -39,7 +39,11 @@
>>
>> static inline u32 crc32_u32(u32 crc, u32 val)
>> {
>>+#ifdef CONFIG_AS_CRC32
>> asm ("crc32l %1,%0\n" : "+r" (crc) : "rm" (val));
>>+#else
>>+ asm (".byte 0xf2, 0x0f, 0x38, 0xf1, 0xc1" : "+a" (crc) : "c" (val));
>>+#endif
>> return crc;
>> }
>>
>
> --
> Sent from my mobile phone. Please pardon brevity and lack of formatting.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/3] x86/hash: fix build failure with older binutils
How old?
On February 21, 2014 2:32:50 AM PST, Jan Beulich wrote:
>Just like for other ISA extension instruction uses we should check
>whether the assembler actually supports them. The fallback here simply
>is to encode an instruction with fixed operands (%eax and %ecx).
>
>Signed-off-by: Jan Beulich
>Cc: Francesco Fusco
>Cc: Daniel Borkmann
>Cc: Thomas Graf
>Cc: David S. Miller
>---
> arch/x86/Makefile |1 +
> arch/x86/lib/hash.c |4
> 2 files changed, 5 insertions(+)
>
>--- 3.14-rc3-x86-hash-crc32.orig/arch/x86/Makefile
>+++ 3.14-rc3-x86-hash-crc32/arch/x86/Makefile
>@@ -152,6 +152,7 @@ cfi-sections := $(call as-instr,.cfi_sec
>
> # does binutils support specific instructions?
> asinstr := $(call as-instr,fxsaveq (%rax),-DCONFIG_AS_FXSAVEQ=1)
>+asinstr += $(call as-instr,crc32l
>%eax$(comma)%eax,-DCONFIG_AS_CRC32=1)
>avx_instr := $(call as-instr,vxorps
>%ymm0$(comma)%ymm1$(comma)%ymm2,-DCONFIG_AS_AVX=1)
>avx2_instr :=$(call as-instr,vpbroadcastb
>%xmm0$(comma)%ymm1,-DCONFIG_AS_AVX2=1)
>
>--- 3.14-rc3-x86-hash-crc32.orig/arch/x86/lib/hash.c
>+++ 3.14-rc3-x86-hash-crc32/arch/x86/lib/hash.c
>@@ -39,7 +39,11 @@
>
> static inline u32 crc32_u32(u32 crc, u32 val)
> {
>+#ifdef CONFIG_AS_CRC32
> asm ("crc32l %1,%0\n" : "+r" (crc) : "rm" (val));
>+#else
>+ asm (".byte 0xf2, 0x0f, 0x38, 0xf1, 0xc1" : "+a" (crc) : "c" (val));
>+#endif
> return crc;
> }
>
--
Sent from my mobile phone. Please pardon brevity and lack of formatting.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
