On Mon, 29 Nov 2010 14:03:35 +1100 Stephen Rothwell wrote:
> Hi all,
>
> Changes since 20101126:
on i386 builds, I get tons of these (and more) errors:
arch/x86/crypto/aesni-intel_asm.S:841: Error: bad register name `%r12'
arch/x86/crypto/aesni-intel_asm.S:842: Error: bad register name `%r13'
arch/x86/crypto/aesni-intel_asm.S:843: Error: bad register name `%r14'
arch/x86/crypto/aesni-intel_asm.S:844: Error: bad register name `%rsp'
arch/x86/crypto/aesni-intel_asm.S:849: Error: bad register name `%rsp'
arch/x86/crypto/aesni-intel_asm.S:850: Error: bad register name `%rsp'
arch/x86/crypto/aesni-intel_asm.S:851: Error: bad register name `%r9'
even though the kernel .config file says:
CONFIG_CRYPTO_AES=m
CONFIG_CRYPTO_AES_586=m
CONFIG_CRYPTO_AES_NI_INTEL=m
Should arch/x86/crypto/aesni-intel_asm.S be testing
#ifdef CONFIG_X86_64
instead of
#ifdef __x86_64__
or does that not matter?
or is this a toolchain issue?
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
On 29.11.2010, 17:31 Randy Dunlap wrote:
> On Mon, 29 Nov 2010 14:03:35 +1100 Stephen Rothwell wrote:
>
>> Hi all,
>>
>> Changes since 20101126:
>
>
> on i386 builds, I get tons of these (and more) errors:
>
> arch/x86/crypto/aesni-intel_asm.S:841: Error: bad register name `%r12'
> arch/x86/crypto/aesni-intel_asm.S:842: Error: bad register name `%r13'
> arch/x86/crypto/aesni-intel_asm.S:843: Error: bad register name `%r14'
> arch/x86/crypto/aesni-intel_asm.S:844: Error: bad register name `%rsp'
> arch/x86/crypto/aesni-intel_asm.S:849: Error: bad register name `%rsp'
> arch/x86/crypto/aesni-intel_asm.S:850: Error: bad register name `%rsp'
> arch/x86/crypto/aesni-intel_asm.S:851: Error: bad register name `%r9'
>
> even though the kernel .config file says:
>
> CONFIG_CRYPTO_AES=m
> CONFIG_CRYPTO_AES_586=m
> CONFIG_CRYPTO_AES_NI_INTEL=m
>
> Should arch/x86/crypto/aesni-intel_asm.S be testing
> #ifdef CONFIG_X86_64
> instead of
> #ifdef __x86_64__
> or does that not matter?
>
> or is this a toolchain issue?
Well, __x86_64__ should be a build-in define of the compiler while
CONFIG_X86_64 is defined for 64 bit builds in include/generated/autoconf.h.
So by using the latter we should be on the safe side but if your compiler
defines __x86_64__ for 32-bit builds it's simply broken. Also git grep
showed quite a few more places using __x86_64__ so those would miscompile on
your toolchain, too.
But it looks like linux-next is just missing
559ad0ff1368baea14dbc3207d55b02bd69bda4b from Herbert's git repo at
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git.
That should fix the build issue.
Kind Regards,
Mathias
On 11/29/10 10:26, Mathias Krause wrote:
> On 29.11.2010, 17:31 Randy Dunlap wrote:
>> On Mon, 29 Nov 2010 14:03:35 +1100 Stephen Rothwell wrote:
>>
>>> Hi all,
>>>
>>> Changes since 20101126:
>>
>>
>> on i386 builds, I get tons of these (and more) errors:
>>
>> arch/x86/crypto/aesni-intel_asm.S:841: Error: bad register name `%r12'
>> arch/x86/crypto/aesni-intel_asm.S:842: Error: bad register name `%r13'
>> arch/x86/crypto/aesni-intel_asm.S:843: Error: bad register name `%r14'
>> arch/x86/crypto/aesni-intel_asm.S:844: Error: bad register name `%rsp'
>> arch/x86/crypto/aesni-intel_asm.S:849: Error: bad register name `%rsp'
>> arch/x86/crypto/aesni-intel_asm.S:850: Error: bad register name `%rsp'
>> arch/x86/crypto/aesni-intel_asm.S:851: Error: bad register name `%r9'
>>
>> even though the kernel .config file says:
>>
>> CONFIG_CRYPTO_AES=m
>> CONFIG_CRYPTO_AES_586=m
>> CONFIG_CRYPTO_AES_NI_INTEL=m
>>
>> Should arch/x86/crypto/aesni-intel_asm.S be testing
>> #ifdef CONFIG_X86_64
>> instead of
>> #ifdef __x86_64__
>> or does that not matter?
>>
>> or is this a toolchain issue?
>
> Well, __x86_64__ should be a build-in define of the compiler while
> CONFIG_X86_64 is defined for 64 bit builds in include/generated/autoconf.h.
> So by using the latter we should be on the safe side but if your compiler
> defines __x86_64__ for 32-bit builds it's simply broken. Also git grep
> showed quite a few more places using __x86_64__ so those would miscompile on
> your toolchain, too.
>
> But it looks like linux-next is just missing
> 559ad0ff1368baea14dbc3207d55b02bd69bda4b from Herbert's git repo at
> git://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git.
> That should fix the build issue.
The build problem still happens when that patch is applied.
--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
On 29.11.2010, 19:54 Randy Dunlap wrote:
> On 11/29/10 10:26, Mathias Krause wrote:
>> On 29.11.2010, 17:31 Randy Dunlap wrote:
>>> On Mon, 29 Nov 2010 14:03:35 +1100 Stephen Rothwell wrote:
>>>
>>>> Hi all,
>>>>
>>>> Changes since 20101126:
>>>
>>>
>>> on i386 builds, I get tons of these (and more) errors:
>>>
>>> arch/x86/crypto/aesni-intel_asm.S:841: Error: bad register name `%r12'
>>> arch/x86/crypto/aesni-intel_asm.S:842: Error: bad register name `%r13'
>>> arch/x86/crypto/aesni-intel_asm.S:843: Error: bad register name `%r14'
>>> arch/x86/crypto/aesni-intel_asm.S:844: Error: bad register name `%rsp'
>>> arch/x86/crypto/aesni-intel_asm.S:849: Error: bad register name `%rsp'
>>> arch/x86/crypto/aesni-intel_asm.S:850: Error: bad register name `%rsp'
>>> arch/x86/crypto/aesni-intel_asm.S:851: Error: bad register name `%r9'
>>>
>>> even though the kernel .config file says:
>>>
>>> CONFIG_CRYPTO_AES=m
>>> CONFIG_CRYPTO_AES_586=m
>>> CONFIG_CRYPTO_AES_NI_INTEL=m
>>>
>>> Should arch/x86/crypto/aesni-intel_asm.S be testing
>>> #ifdef CONFIG_X86_64
>>> instead of
>>> #ifdef __x86_64__
>>> or does that not matter?
>>>
>>> or is this a toolchain issue?
>>
>> Well, __x86_64__ should be a build-in define of the compiler while
>> CONFIG_X86_64 is defined for 64 bit builds in include/generated/autoconf.h.
>> So by using the latter we should be on the safe side but if your compiler
>> defines __x86_64__ for 32-bit builds it's simply broken. Also git grep
>> showed quite a few more places using __x86_64__ so those would miscompile on
>> your toolchain, too.
>>
>> But it looks like linux-next is just missing
>> 559ad0ff1368baea14dbc3207d55b02bd69bda4b from Herbert's git repo at
>> git://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git.
>> That should fix the build issue.
>
> The build problem still happens when that patch is applied.
That's weird. So it must be something with your toolchain.
Can you please post the output of the following commands?:
$ touch /tmp/null.c; cc -m32 -dD -E /tmp/null.c | grep -E 'x86|i.86'
$ touch /tmp/null.c; cc -m64 -dD -E /tmp/null.c | grep -E 'x86|i.86'
Beside that, the patch below should fix the issue with your toolchain by using
CONFIG_X86_64 instead of __x86_64__.
Sorry for the inconvenience,
Mathias
[PATCH] crypto: aesni-intel - Fixed another build error on x86-32
It looks like not all compilers undef __x86_64__ for 32-bit builds so
switch to CONFIG_X86_64 to test if we're building for 64 or 32 bit.
Signed-off-by: Mathias Krause <[email protected]>
---
arch/x86/crypto/aesni-intel_asm.S | 40 ++++++++++++++++++------------------
1 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/arch/x86/crypto/aesni-intel_asm.S b/arch/x86/crypto/aesni-intel_asm.S
index d528fde..de0ec32 100644
--- a/arch/x86/crypto/aesni-intel_asm.S
+++ b/arch/x86/crypto/aesni-intel_asm.S
@@ -32,7 +32,7 @@
#include <linux/linkage.h>
#include <asm/inst.h>
-#ifdef __x86_64__
+#ifdef CONFIG_X86_64
.data
POLY: .octa 0xC2000000000000000000000000000001
TWOONE: .octa 0x00000001000000000000000000000001
@@ -105,7 +105,7 @@ enc: .octa 0x2
#define CTR %xmm11
#define INC %xmm12
-#ifdef __x86_64__
+#ifdef CONFIG_X86_64
#define AREG %rax
#define KEYP %rdi
#define OUTP %rsi
@@ -132,7 +132,7 @@ enc: .octa 0x2
#endif
-#ifdef __x86_64__
+#ifdef CONFIG_X86_64
/* GHASH_MUL MACRO to implement: Data*HashKey mod (128,127,126,121,0)
*
*
@@ -1333,7 +1333,7 @@ _key_expansion_256b:
* unsigned int key_len)
*/
ENTRY(aesni_set_key)
-#ifndef __x86_64__
+#ifndef CONFIG_X86_64
pushl KEYP
movl 8(%esp), KEYP # ctx
movl 12(%esp), UKEYP # in_key
@@ -1435,7 +1435,7 @@ ENTRY(aesni_set_key)
cmp TKEYP, KEYP
jb .Ldec_key_loop
xor AREG, AREG
-#ifndef __x86_64__
+#ifndef CONFIG_X86_64
popl KEYP
#endif
ret
@@ -1444,7 +1444,7 @@ ENTRY(aesni_set_key)
* void aesni_enc(struct crypto_aes_ctx *ctx, u8 *dst, const u8 *src)
*/
ENTRY(aesni_enc)
-#ifndef __x86_64__
+#ifndef CONFIG_X86_64
pushl KEYP
pushl KLEN
movl 12(%esp), KEYP
@@ -1455,7 +1455,7 @@ ENTRY(aesni_enc)
movups (INP), STATE # input
call _aesni_enc1
movups STATE, (OUTP) # output
-#ifndef __x86_64__
+#ifndef CONFIG_X86_64
popl KLEN
popl KEYP
#endif
@@ -1630,7 +1630,7 @@ _aesni_enc4:
* void aesni_dec (struct crypto_aes_ctx *ctx, u8 *dst, const u8 *src)
*/
ENTRY(aesni_dec)
-#ifndef __x86_64__
+#ifndef CONFIG_X86_64
pushl KEYP
pushl KLEN
movl 12(%esp), KEYP
@@ -1642,7 +1642,7 @@ ENTRY(aesni_dec)
movups (INP), STATE # input
call _aesni_dec1
movups STATE, (OUTP) #output
-#ifndef __x86_64__
+#ifndef CONFIG_X86_64
popl KLEN
popl KEYP
#endif
@@ -1818,7 +1818,7 @@ _aesni_dec4:
* size_t len)
*/
ENTRY(aesni_ecb_enc)
-#ifndef __x86_64__
+#ifndef CONFIG_X86_64
pushl LEN
pushl KEYP
pushl KLEN
@@ -1863,7 +1863,7 @@ ENTRY(aesni_ecb_enc)
cmp $16, LEN
jge .Lecb_enc_loop1
.Lecb_enc_ret:
-#ifndef __x86_64__
+#ifndef CONFIG_X86_64
popl KLEN
popl KEYP
popl LEN
@@ -1875,7 +1875,7 @@ ENTRY(aesni_ecb_enc)
* size_t len);
*/
ENTRY(aesni_ecb_dec)
-#ifndef __x86_64__
+#ifndef CONFIG_X86_64
pushl LEN
pushl KEYP
pushl KLEN
@@ -1921,7 +1921,7 @@ ENTRY(aesni_ecb_dec)
cmp $16, LEN
jge .Lecb_dec_loop1
.Lecb_dec_ret:
-#ifndef __x86_64__
+#ifndef CONFIG_X86_64
popl KLEN
popl KEYP
popl LEN
@@ -1933,7 +1933,7 @@ ENTRY(aesni_ecb_dec)
* size_t len, u8 *iv)
*/
ENTRY(aesni_cbc_enc)
-#ifndef __x86_64__
+#ifndef CONFIG_X86_64
pushl IVP
pushl LEN
pushl KEYP
@@ -1961,7 +1961,7 @@ ENTRY(aesni_cbc_enc)
jge .Lcbc_enc_loop
movups STATE, (IVP)
.Lcbc_enc_ret:
-#ifndef __x86_64__
+#ifndef CONFIG_X86_64
popl KLEN
popl KEYP
popl LEN
@@ -1974,7 +1974,7 @@ ENTRY(aesni_cbc_enc)
* size_t len, u8 *iv)
*/
ENTRY(aesni_cbc_dec)
-#ifndef __x86_64__
+#ifndef CONFIG_X86_64
pushl IVP
pushl LEN
pushl KEYP
@@ -1998,7 +1998,7 @@ ENTRY(aesni_cbc_dec)
movaps IN1, STATE1
movups 0x10(INP), IN2
movaps IN2, STATE2
-#ifdef __x86_64__
+#ifdef CONFIG_X86_64
movups 0x20(INP), IN3
movaps IN3, STATE3
movups 0x30(INP), IN4
@@ -2011,7 +2011,7 @@ ENTRY(aesni_cbc_dec)
#endif
call _aesni_dec4
pxor IV, STATE1
-#ifdef __x86_64__
+#ifdef CONFIG_X86_64
pxor IN1, STATE2
pxor IN2, STATE3
pxor IN3, STATE4
@@ -2049,7 +2049,7 @@ ENTRY(aesni_cbc_dec)
.Lcbc_dec_ret:
movups IV, (IVP)
.Lcbc_dec_just_ret:
-#ifndef __x86_64__
+#ifndef CONFIG_X86_64
popl KLEN
popl KEYP
popl LEN
@@ -2057,7 +2057,7 @@ ENTRY(aesni_cbc_dec)
#endif
ret
-#ifdef __x86_64__
+#ifdef CONFIG_X86_64
.align 16
.Lbswap_mask:
.byte 15, 14, 13, 12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1, 0
--
1.5.6.5
On 11/29/10 11:21, Mathias Krause wrote:
> On 29.11.2010, 19:54 Randy Dunlap wrote:
>> On 11/29/10 10:26, Mathias Krause wrote:
>>> On 29.11.2010, 17:31 Randy Dunlap wrote:
>>>> On Mon, 29 Nov 2010 14:03:35 +1100 Stephen Rothwell wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> Changes since 20101126:
>>>>
>>>>
>>>> on i386 builds, I get tons of these (and more) errors:
>>>>
>>>> arch/x86/crypto/aesni-intel_asm.S:841: Error: bad register name `%r12'
>>>> arch/x86/crypto/aesni-intel_asm.S:842: Error: bad register name `%r13'
>>>> arch/x86/crypto/aesni-intel_asm.S:843: Error: bad register name `%r14'
>>>> arch/x86/crypto/aesni-intel_asm.S:844: Error: bad register name `%rsp'
>>>> arch/x86/crypto/aesni-intel_asm.S:849: Error: bad register name `%rsp'
>>>> arch/x86/crypto/aesni-intel_asm.S:850: Error: bad register name `%rsp'
>>>> arch/x86/crypto/aesni-intel_asm.S:851: Error: bad register name `%r9'
>>>>
>>>> even though the kernel .config file says:
>>>>
>>>> CONFIG_CRYPTO_AES=m
>>>> CONFIG_CRYPTO_AES_586=m
>>>> CONFIG_CRYPTO_AES_NI_INTEL=m
>>>>
>>>> Should arch/x86/crypto/aesni-intel_asm.S be testing
>>>> #ifdef CONFIG_X86_64
>>>> instead of
>>>> #ifdef __x86_64__
>>>> or does that not matter?
>>>>
>>>> or is this a toolchain issue?
>>>
>>> Well, __x86_64__ should be a build-in define of the compiler while
>>> CONFIG_X86_64 is defined for 64 bit builds in include/generated/autoconf.h.
>>> So by using the latter we should be on the safe side but if your compiler
>>> defines __x86_64__ for 32-bit builds it's simply broken. Also git grep
>>> showed quite a few more places using __x86_64__ so those would miscompile on
>>> your toolchain, too.
>>>
>>> But it looks like linux-next is just missing
>>> 559ad0ff1368baea14dbc3207d55b02bd69bda4b from Herbert's git repo at
>>> git://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git.
>>> That should fix the build issue.
>>
>> The build problem still happens when that patch is applied.
>
> That's weird. So it must be something with your toolchain.
> Can you please post the output of the following commands?:
>
> $ touch /tmp/null.c; cc -m32 -dD -E /tmp/null.c | grep -E 'x86|i.86'
#define __i386 1
#define __i386__ 1
#define i386 1
#define __i586 1
#define __i586__ 1
> $ touch /tmp/null.c; cc -m64 -dD -E /tmp/null.c | grep -E 'x86|i.86'
#define __x86_64 1
#define __x86_64__ 1
So that's not the problem... and the patch below didn't help.
Sorry that I even asked about that. What next?
> Beside that, the patch below should fix the issue with your toolchain by using
> CONFIG_X86_64 instead of __x86_64__.
>
> Sorry for the inconvenience,
> Mathias
>
> [PATCH] crypto: aesni-intel - Fixed another build error on x86-32
>
> It looks like not all compilers undef __x86_64__ for 32-bit builds so
> switch to CONFIG_X86_64 to test if we're building for 64 or 32 bit.
>
> Signed-off-by: Mathias Krause <[email protected]>
> ---
> arch/x86/crypto/aesni-intel_asm.S | 40 ++++++++++++++++++------------------
> 1 files changed, 20 insertions(+), 20 deletions(-)
>
> diff --git a/arch/x86/crypto/aesni-intel_asm.S b/arch/x86/crypto/aesni-intel_asm.S
> index d528fde..de0ec32 100644
> --- a/arch/x86/crypto/aesni-intel_asm.S
> +++ b/arch/x86/crypto/aesni-intel_asm.S
> @@ -32,7 +32,7 @@
> #include <linux/linkage.h>
> #include <asm/inst.h>
>
> -#ifdef __x86_64__
> +#ifdef CONFIG_X86_64
> .data
> POLY: .octa 0xC2000000000000000000000000000001
> TWOONE: .octa 0x00000001000000000000000000000001
> @@ -105,7 +105,7 @@ enc: .octa 0x2
> #define CTR %xmm11
> #define INC %xmm12
>
> -#ifdef __x86_64__
> +#ifdef CONFIG_X86_64
> #define AREG %rax
> #define KEYP %rdi
> #define OUTP %rsi
> @@ -132,7 +132,7 @@ enc: .octa 0x2
> #endif
>
>
> -#ifdef __x86_64__
> +#ifdef CONFIG_X86_64
> /* GHASH_MUL MACRO to implement: Data*HashKey mod (128,127,126,121,0)
> *
> *
> @@ -1333,7 +1333,7 @@ _key_expansion_256b:
> * unsigned int key_len)
> */
> ENTRY(aesni_set_key)
> -#ifndef __x86_64__
> +#ifndef CONFIG_X86_64
> pushl KEYP
> movl 8(%esp), KEYP # ctx
> movl 12(%esp), UKEYP # in_key
> @@ -1435,7 +1435,7 @@ ENTRY(aesni_set_key)
> cmp TKEYP, KEYP
> jb .Ldec_key_loop
> xor AREG, AREG
> -#ifndef __x86_64__
> +#ifndef CONFIG_X86_64
> popl KEYP
> #endif
> ret
> @@ -1444,7 +1444,7 @@ ENTRY(aesni_set_key)
> * void aesni_enc(struct crypto_aes_ctx *ctx, u8 *dst, const u8 *src)
> */
> ENTRY(aesni_enc)
> -#ifndef __x86_64__
> +#ifndef CONFIG_X86_64
> pushl KEYP
> pushl KLEN
> movl 12(%esp), KEYP
> @@ -1455,7 +1455,7 @@ ENTRY(aesni_enc)
> movups (INP), STATE # input
> call _aesni_enc1
> movups STATE, (OUTP) # output
> -#ifndef __x86_64__
> +#ifndef CONFIG_X86_64
> popl KLEN
> popl KEYP
> #endif
> @@ -1630,7 +1630,7 @@ _aesni_enc4:
> * void aesni_dec (struct crypto_aes_ctx *ctx, u8 *dst, const u8 *src)
> */
> ENTRY(aesni_dec)
> -#ifndef __x86_64__
> +#ifndef CONFIG_X86_64
> pushl KEYP
> pushl KLEN
> movl 12(%esp), KEYP
> @@ -1642,7 +1642,7 @@ ENTRY(aesni_dec)
> movups (INP), STATE # input
> call _aesni_dec1
> movups STATE, (OUTP) #output
> -#ifndef __x86_64__
> +#ifndef CONFIG_X86_64
> popl KLEN
> popl KEYP
> #endif
> @@ -1818,7 +1818,7 @@ _aesni_dec4:
> * size_t len)
> */
> ENTRY(aesni_ecb_enc)
> -#ifndef __x86_64__
> +#ifndef CONFIG_X86_64
> pushl LEN
> pushl KEYP
> pushl KLEN
> @@ -1863,7 +1863,7 @@ ENTRY(aesni_ecb_enc)
> cmp $16, LEN
> jge .Lecb_enc_loop1
> .Lecb_enc_ret:
> -#ifndef __x86_64__
> +#ifndef CONFIG_X86_64
> popl KLEN
> popl KEYP
> popl LEN
> @@ -1875,7 +1875,7 @@ ENTRY(aesni_ecb_enc)
> * size_t len);
> */
> ENTRY(aesni_ecb_dec)
> -#ifndef __x86_64__
> +#ifndef CONFIG_X86_64
> pushl LEN
> pushl KEYP
> pushl KLEN
> @@ -1921,7 +1921,7 @@ ENTRY(aesni_ecb_dec)
> cmp $16, LEN
> jge .Lecb_dec_loop1
> .Lecb_dec_ret:
> -#ifndef __x86_64__
> +#ifndef CONFIG_X86_64
> popl KLEN
> popl KEYP
> popl LEN
> @@ -1933,7 +1933,7 @@ ENTRY(aesni_ecb_dec)
> * size_t len, u8 *iv)
> */
> ENTRY(aesni_cbc_enc)
> -#ifndef __x86_64__
> +#ifndef CONFIG_X86_64
> pushl IVP
> pushl LEN
> pushl KEYP
> @@ -1961,7 +1961,7 @@ ENTRY(aesni_cbc_enc)
> jge .Lcbc_enc_loop
> movups STATE, (IVP)
> .Lcbc_enc_ret:
> -#ifndef __x86_64__
> +#ifndef CONFIG_X86_64
> popl KLEN
> popl KEYP
> popl LEN
> @@ -1974,7 +1974,7 @@ ENTRY(aesni_cbc_enc)
> * size_t len, u8 *iv)
> */
> ENTRY(aesni_cbc_dec)
> -#ifndef __x86_64__
> +#ifndef CONFIG_X86_64
> pushl IVP
> pushl LEN
> pushl KEYP
> @@ -1998,7 +1998,7 @@ ENTRY(aesni_cbc_dec)
> movaps IN1, STATE1
> movups 0x10(INP), IN2
> movaps IN2, STATE2
> -#ifdef __x86_64__
> +#ifdef CONFIG_X86_64
> movups 0x20(INP), IN3
> movaps IN3, STATE3
> movups 0x30(INP), IN4
> @@ -2011,7 +2011,7 @@ ENTRY(aesni_cbc_dec)
> #endif
> call _aesni_dec4
> pxor IV, STATE1
> -#ifdef __x86_64__
> +#ifdef CONFIG_X86_64
> pxor IN1, STATE2
> pxor IN2, STATE3
> pxor IN3, STATE4
> @@ -2049,7 +2049,7 @@ ENTRY(aesni_cbc_dec)
> .Lcbc_dec_ret:
> movups IV, (IVP)
> .Lcbc_dec_just_ret:
> -#ifndef __x86_64__
> +#ifndef CONFIG_X86_64
> popl KLEN
> popl KEYP
> popl LEN
> @@ -2057,7 +2057,7 @@ ENTRY(aesni_cbc_dec)
> #endif
> ret
>
> -#ifdef __x86_64__
> +#ifdef CONFIG_X86_64
> .align 16
> .Lbswap_mask:
> .byte 15, 14, 13, 12, 11, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1, 0
--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
On 29.11.2010, 20:31 Randy Dunlap wrote:
> On 11/29/10 11:21, Mathias Krause wrote:
>> On 29.11.2010, 19:54 Randy Dunlap wrote:
>>> On 11/29/10 10:26, Mathias Krause wrote:
>>>> On 29.11.2010, 17:31 Randy Dunlap wrote:
>>>>> On Mon, 29 Nov 2010 14:03:35 +1100 Stephen Rothwell wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> Changes since 20101126:
>>>>>
>>>>>
>>>>> on i386 builds, I get tons of these (and more) errors:
>>>>>
>>>>> arch/x86/crypto/aesni-intel_asm.S:841: Error: bad register name `%r12'
>>>>> arch/x86/crypto/aesni-intel_asm.S:842: Error: bad register name `%r13'
>>>>> arch/x86/crypto/aesni-intel_asm.S:843: Error: bad register name `%r14'
>>>>> arch/x86/crypto/aesni-intel_asm.S:844: Error: bad register name `%rsp'
>>>>> arch/x86/crypto/aesni-intel_asm.S:849: Error: bad register name `%rsp'
>>>>> arch/x86/crypto/aesni-intel_asm.S:850: Error: bad register name `%rsp'
>>>>> arch/x86/crypto/aesni-intel_asm.S:851: Error: bad register name `%r9'
>>>>>
>>>>> even though the kernel .config file says:
>>>>>
>>>>> CONFIG_CRYPTO_AES=m
>>>>> CONFIG_CRYPTO_AES_586=m
>>>>> CONFIG_CRYPTO_AES_NI_INTEL=m
>>>>>
>>>>> Should arch/x86/crypto/aesni-intel_asm.S be testing
>>>>> #ifdef CONFIG_X86_64
>>>>> instead of
>>>>> #ifdef __x86_64__
>>>>> or does that not matter?
>>>>>
>>>>> or is this a toolchain issue?
>>>>
>>>> Well, __x86_64__ should be a build-in define of the compiler while
>>>> CONFIG_X86_64 is defined for 64 bit builds in include/generated/autoconf.h.
>>>> So by using the latter we should be on the safe side but if your compiler
>>>> defines __x86_64__ for 32-bit builds it's simply broken. Also git grep
>>>> showed quite a few more places using __x86_64__ so those would miscompile on
>>>> your toolchain, too.
>>>>
>>>> But it looks like linux-next is just missing
>>>> 559ad0ff1368baea14dbc3207d55b02bd69bda4b from Herbert's git repo at
>>>> git://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git.
>>>> That should fix the build issue.
>>>
>>> The build problem still happens when that patch is applied.
>>
>> That's weird. So it must be something with your toolchain.
>> Can you please post the output of the following commands?:
>>
>> $ touch /tmp/null.c; cc -m32 -dD -E /tmp/null.c | grep -E 'x86|i.86'
>
> #define __i386 1
> #define __i386__ 1
> #define i386 1
> #define __i586 1
> #define __i586__ 1
>
>> $ touch /tmp/null.c; cc -m64 -dD -E /tmp/null.c | grep -E 'x86|i.86'
>
> #define __x86_64 1
> #define __x86_64__ 1
>
> So that's not the problem... and the patch below didn't help.
That's odd. The output of the commands looks good so the x86-64 specific code
should be left out for 32-bit builds. :/
> Sorry that I even asked about that. What next?
Can you please post the full error message. Meanwhile I'm checking out a
linux-next tree, trying to reproduce your problem.
On 29.11.2010, 20:31 Randy Dunlap wrote:
> On 11/29/10 11:21, Mathias Krause wrote:
>> On 29.11.2010, 19:54 Randy Dunlap wrote:
>>> On 11/29/10 10:26, Mathias Krause wrote:
>>>> On 29.11.2010, 17:31 Randy Dunlap wrote:
>>>>> On Mon, 29 Nov 2010 14:03:35 +1100 Stephen Rothwell wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> Changes since 20101126:
>>>>>
>>>>>
>>>>> on i386 builds, I get tons of these (and more) errors:
>>>>>
>>>>> arch/x86/crypto/aesni-intel_asm.S:841: Error: bad register name `%r12'
>>>>> arch/x86/crypto/aesni-intel_asm.S:842: Error: bad register name `%r13'
>>>>> arch/x86/crypto/aesni-intel_asm.S:843: Error: bad register name `%r14'
>>>>> arch/x86/crypto/aesni-intel_asm.S:844: Error: bad register name `%rsp'
>>>>> arch/x86/crypto/aesni-intel_asm.S:849: Error: bad register name `%rsp'
>>>>> arch/x86/crypto/aesni-intel_asm.S:850: Error: bad register name `%rsp'
>>>>> arch/x86/crypto/aesni-intel_asm.S:851: Error: bad register name `%r9'
>>>>>
>>>>> even though the kernel .config file says:
>>>>>
>>>>> CONFIG_CRYPTO_AES=m
>>>>> CONFIG_CRYPTO_AES_586=m
>>>>> CONFIG_CRYPTO_AES_NI_INTEL=m
>>>>>
>>>>> Should arch/x86/crypto/aesni-intel_asm.S be testing
>>>>> #ifdef CONFIG_X86_64
>>>>> instead of
>>>>> #ifdef __x86_64__
>>>>> or does that not matter?
>>>>>
>>>>> or is this a toolchain issue?
>>>>
>>>> Well, __x86_64__ should be a build-in define of the compiler while
>>>> CONFIG_X86_64 is defined for 64 bit builds in include/generated/autoconf.h.
>>>> So by using the latter we should be on the safe side but if your compiler
>>>> defines __x86_64__ for 32-bit builds it's simply broken. Also git grep
>>>> showed quite a few more places using __x86_64__ so those would miscompile on
>>>> your toolchain, too.
>>>>
>>>> But it looks like linux-next is just missing
>>>> 559ad0ff1368baea14dbc3207d55b02bd69bda4b from Herbert's git repo at
>>>> git://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git.
>>>> That should fix the build issue.
>>>
>>> The build problem still happens when that patch is applied.
>>
>> That's weird. So it must be something with your toolchain.
>> Can you please post the output of the following commands?:
>>
>> $ touch /tmp/null.c; cc -m32 -dD -E /tmp/null.c | grep -E 'x86|i.86'
>
> #define __i386 1
> #define __i386__ 1
> #define i386 1
> #define __i586 1
> #define __i586__ 1
>
>> $ touch /tmp/null.c; cc -m64 -dD -E /tmp/null.c | grep -E 'x86|i.86'
>
> #define __x86_64 1
> #define __x86_64__ 1
>
> So that's not the problem... and the patch below didn't help.
> Sorry that I even asked about that. What next?
Sorry, I cannot reproduce the problem with the latest linux-next and commit
559ad0ff1368baea14dbc3207d55b02bd69bda4b from cryptodev-2.6 applied. Please
ensure you've applied that patch.
Regards,
Mathias
On 11/29/10 11:45, Mathias Krause wrote:
> On 29.11.2010, 20:31 Randy Dunlap wrote:
>> On 11/29/10 11:21, Mathias Krause wrote:
>>> On 29.11.2010, 19:54 Randy Dunlap wrote:
>>>> On 11/29/10 10:26, Mathias Krause wrote:
>>>>> On 29.11.2010, 17:31 Randy Dunlap wrote:
>>>>>> On Mon, 29 Nov 2010 14:03:35 +1100 Stephen Rothwell wrote:
>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> Changes since 20101126:
>>>>>>
>>>>>>
>>>>>> on i386 builds, I get tons of these (and more) errors:
>>>>>>
>>>>>> arch/x86/crypto/aesni-intel_asm.S:841: Error: bad register name `%r12'
>>>>>> arch/x86/crypto/aesni-intel_asm.S:842: Error: bad register name `%r13'
>>>>>> arch/x86/crypto/aesni-intel_asm.S:843: Error: bad register name `%r14'
>>>>>> arch/x86/crypto/aesni-intel_asm.S:844: Error: bad register name `%rsp'
>>>>>> arch/x86/crypto/aesni-intel_asm.S:849: Error: bad register name `%rsp'
>>>>>> arch/x86/crypto/aesni-intel_asm.S:850: Error: bad register name `%rsp'
>>>>>> arch/x86/crypto/aesni-intel_asm.S:851: Error: bad register name `%r9'
>>>>>>
>>>>>> even though the kernel .config file says:
>>>>>>
>>>>>> CONFIG_CRYPTO_AES=m
>>>>>> CONFIG_CRYPTO_AES_586=m
>>>>>> CONFIG_CRYPTO_AES_NI_INTEL=m
>>>>>>
>>>>>> Should arch/x86/crypto/aesni-intel_asm.S be testing
>>>>>> #ifdef CONFIG_X86_64
>>>>>> instead of
>>>>>> #ifdef __x86_64__
>>>>>> or does that not matter?
>>>>>>
>>>>>> or is this a toolchain issue?
>>>>>
>>>>> Well, __x86_64__ should be a build-in define of the compiler while
>>>>> CONFIG_X86_64 is defined for 64 bit builds in include/generated/autoconf.h.
>>>>> So by using the latter we should be on the safe side but if your compiler
>>>>> defines __x86_64__ for 32-bit builds it's simply broken. Also git grep
>>>>> showed quite a few more places using __x86_64__ so those would miscompile on
>>>>> your toolchain, too.
>>>>>
>>>>> But it looks like linux-next is just missing
>>>>> 559ad0ff1368baea14dbc3207d55b02bd69bda4b from Herbert's git repo at
>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git.
>>>>> That should fix the build issue.
>>>>
>>>> The build problem still happens when that patch is applied.
>>>
>>> That's weird. So it must be something with your toolchain.
>>> Can you please post the output of the following commands?:
>>>
>>> $ touch /tmp/null.c; cc -m32 -dD -E /tmp/null.c | grep -E 'x86|i.86'
>>
>> #define __i386 1
>> #define __i386__ 1
>> #define i386 1
>> #define __i586 1
>> #define __i586__ 1
>>
>>> $ touch /tmp/null.c; cc -m64 -dD -E /tmp/null.c | grep -E 'x86|i.86'
>>
>> #define __x86_64 1
>> #define __x86_64__ 1
>>
>> So that's not the problem... and the patch below didn't help.
>
> That's odd. The output of the commands looks good so the x86-64 specific code
> should be left out for 32-bit builds. :/
>
>> Sorry that I even asked about that. What next?
>
> Can you please post the full error message. Meanwhile I'm checking out a
> linux-next tree, trying to reproduce your problem.
>
I just built with "make V=1" to see the full commands that are used, but
that didn't help me either:
gcc -Wp,-MD,arch/x86/crypto/.aesni-intel_asm.o.d -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/4.4.1/include -I/lnx/src/NEXT/linux-next-20101129/arch/x86/include -Iinclude -I/lnx/src/NEXT/linux-next-20101129/include -include include/generated/autoconf.h -D__KERNEL__ -D__ASSEMBLY__ -m32 -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DMODULE -c -o arch/x86/crypto/aesni-intel_asm.o /lnx/src/NEXT/linux-next-20101129/arch/x86/crypto/aesni-intel_asm.S
There are 2945 lines like this:
linux-next-20101129/arch/x86/crypto/aesni-intel_asm.S:841: Error: bad register name `%r12'
It's around 311 KB, so I'll just put it here instead of emailing it:
http://oss.oracle.com/~rdunlap/doc/cry32.out
--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
On 11/29/10 11:52, Mathias Krause wrote:
> On 29.11.2010, 20:31 Randy Dunlap wrote:
>> On 11/29/10 11:21, Mathias Krause wrote:
>>> On 29.11.2010, 19:54 Randy Dunlap wrote:
>>>> On 11/29/10 10:26, Mathias Krause wrote:
>>>>> On 29.11.2010, 17:31 Randy Dunlap wrote:
>>>>>> On Mon, 29 Nov 2010 14:03:35 +1100 Stephen Rothwell wrote:
>>>>>>
>>>>>>> Hi all,
>>>>>>>
>>>>>>> Changes since 20101126:
>>>>>>
>>>>>>
>>>>>> on i386 builds, I get tons of these (and more) errors:
>>>>>>
>>>>>> arch/x86/crypto/aesni-intel_asm.S:841: Error: bad register name `%r12'
>>>>>> arch/x86/crypto/aesni-intel_asm.S:842: Error: bad register name `%r13'
>>>>>> arch/x86/crypto/aesni-intel_asm.S:843: Error: bad register name `%r14'
>>>>>> arch/x86/crypto/aesni-intel_asm.S:844: Error: bad register name `%rsp'
>>>>>> arch/x86/crypto/aesni-intel_asm.S:849: Error: bad register name `%rsp'
>>>>>> arch/x86/crypto/aesni-intel_asm.S:850: Error: bad register name `%rsp'
>>>>>> arch/x86/crypto/aesni-intel_asm.S:851: Error: bad register name `%r9'
>>>>>>
>>>>>> even though the kernel .config file says:
>>>>>>
>>>>>> CONFIG_CRYPTO_AES=m
>>>>>> CONFIG_CRYPTO_AES_586=m
>>>>>> CONFIG_CRYPTO_AES_NI_INTEL=m
>>>>>>
>>>>>> Should arch/x86/crypto/aesni-intel_asm.S be testing
>>>>>> #ifdef CONFIG_X86_64
>>>>>> instead of
>>>>>> #ifdef __x86_64__
>>>>>> or does that not matter?
>>>>>>
>>>>>> or is this a toolchain issue?
>>>>>
>>>>> Well, __x86_64__ should be a build-in define of the compiler while
>>>>> CONFIG_X86_64 is defined for 64 bit builds in include/generated/autoconf.h.
>>>>> So by using the latter we should be on the safe side but if your compiler
>>>>> defines __x86_64__ for 32-bit builds it's simply broken. Also git grep
>>>>> showed quite a few more places using __x86_64__ so those would miscompile on
>>>>> your toolchain, too.
>>>>>
>>>>> But it looks like linux-next is just missing
>>>>> 559ad0ff1368baea14dbc3207d55b02bd69bda4b from Herbert's git repo at
>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git.
>>>>> That should fix the build issue.
>>>>
>>>> The build problem still happens when that patch is applied.
>>>
>>> That's weird. So it must be something with your toolchain.
>>> Can you please post the output of the following commands?:
>>>
>>> $ touch /tmp/null.c; cc -m32 -dD -E /tmp/null.c | grep -E 'x86|i.86'
>>
>> #define __i386 1
>> #define __i386__ 1
>> #define i386 1
>> #define __i586 1
>> #define __i586__ 1
>>
>>> $ touch /tmp/null.c; cc -m64 -dD -E /tmp/null.c | grep -E 'x86|i.86'
>>
>> #define __x86_64 1
>> #define __x86_64__ 1
>>
>> So that's not the problem... and the patch below didn't help.
>> Sorry that I even asked about that. What next?
>
> Sorry, I cannot reproduce the problem with the latest linux-next and commit
> 559ad0ff1368baea14dbc3207d55b02bd69bda4b from cryptodev-2.6 applied. Please
> ensure you've applied that patch.
OK, thanks for trying.
Yes, I have applied that patch.
--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
On 29.11.2010, 20:54 Randy Dunlap wrote:
> On 11/29/10 11:45, Mathias Krause wrote:
>> On 29.11.2010, 20:31 Randy Dunlap wrote:
>>> On 11/29/10 11:21, Mathias Krause wrote:
>>>> On 29.11.2010, 19:54 Randy Dunlap wrote:
>>>>> On 11/29/10 10:26, Mathias Krause wrote:
>>>>>> On 29.11.2010, 17:31 Randy Dunlap wrote:
>>>>>>> On Mon, 29 Nov 2010 14:03:35 +1100 Stephen Rothwell wrote:
>>>>>>>
>>>>>>>> Hi all,
>>>>>>>>
>>>>>>>> Changes since 20101126:
>>>>>>>
>>>>>>>
>>>>>>> on i386 builds, I get tons of these (and more) errors:
>>>>>>>
>>>>>>> arch/x86/crypto/aesni-intel_asm.S:841: Error: bad register name `%r12'
>>>>>>> arch/x86/crypto/aesni-intel_asm.S:842: Error: bad register name `%r13'
>>>>>>> arch/x86/crypto/aesni-intel_asm.S:843: Error: bad register name `%r14'
>>>>>>> arch/x86/crypto/aesni-intel_asm.S:844: Error: bad register name `%rsp'
>>>>>>> arch/x86/crypto/aesni-intel_asm.S:849: Error: bad register name `%rsp'
>>>>>>> arch/x86/crypto/aesni-intel_asm.S:850: Error: bad register name `%rsp'
>>>>>>> arch/x86/crypto/aesni-intel_asm.S:851: Error: bad register name `%r9'
>>>>>>>
>>>>>>> even though the kernel .config file says:
>>>>>>>
>>>>>>> CONFIG_CRYPTO_AES=m
>>>>>>> CONFIG_CRYPTO_AES_586=m
>>>>>>> CONFIG_CRYPTO_AES_NI_INTEL=m
>>>>>>>
>>>>>>> Should arch/x86/crypto/aesni-intel_asm.S be testing
>>>>>>> #ifdef CONFIG_X86_64
>>>>>>> instead of
>>>>>>> #ifdef __x86_64__
>>>>>>> or does that not matter?
>>>>>>>
>>>>>>> or is this a toolchain issue?
>>>>>>
>>>>>> Well, __x86_64__ should be a build-in define of the compiler while
>>>>>> CONFIG_X86_64 is defined for 64 bit builds in include/generated/autoconf.h.
>>>>>> So by using the latter we should be on the safe side but if your compiler
>>>>>> defines __x86_64__ for 32-bit builds it's simply broken. Also git grep
>>>>>> showed quite a few more places using __x86_64__ so those would miscompile on
>>>>>> your toolchain, too.
>>>>>>
>>>>>> But it looks like linux-next is just missing
>>>>>> 559ad0ff1368baea14dbc3207d55b02bd69bda4b from Herbert's git repo at
>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git.
>>>>>> That should fix the build issue.
>>>>>
>>>>> The build problem still happens when that patch is applied.
>>>>
>>>> That's weird. So it must be something with your toolchain.
>>>> Can you please post the output of the following commands?:
>>>>
>>>> $ touch /tmp/null.c; cc -m32 -dD -E /tmp/null.c | grep -E 'x86|i.86'
>>>
>>> #define __i386 1
>>> #define __i386__ 1
>>> #define i386 1
>>> #define __i586 1
>>> #define __i586__ 1
>>>
>>>> $ touch /tmp/null.c; cc -m64 -dD -E /tmp/null.c | grep -E 'x86|i.86'
>>>
>>> #define __x86_64 1
>>> #define __x86_64__ 1
>>>
>>> So that's not the problem... and the patch below didn't help.
>>
>> That's odd. The output of the commands looks good so the x86-64 specific code
>> should be left out for 32-bit builds. :/
>>
>>> Sorry that I even asked about that. What next?
>>
>> Can you please post the full error message. Meanwhile I'm checking out a
>> linux-next tree, trying to reproduce your problem.
>>
>
> I just built with "make V=1" to see the full commands that are used, but
> that didn't help me either:
>
> gcc -Wp,-MD,arch/x86/crypto/.aesni-intel_asm.o.d -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/4.4.1/include -I/lnx/src/NEXT/linux-next-20101129/arch/x86/include -Iinclude -I/lnx/src/NEXT/linux-next-20101129/include -include include/generated/autoconf.h -D__KERNEL__ -D__ASSEMBLY__ -m32 -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DMODULE -c -o arch/x86/crypto/aesni-intel_asm.o /lnx/src/NEXT/linux-next-20101129/arch/x86/crypto/aesni-intel_asm.S
>
>
> There are 2945 lines like this:
>
> linux-next-20101129/arch/x86/crypto/aesni-intel_asm.S:841: Error: bad register name `%r12'
Well, in my tree (linux-next + 559ad0ff) line 841 is a comment. Albeit without
559ad0ff it's a 'push %r12'. So maybe you should apply the patch just once
more to be sure. ;)
> It's around 311 KB, so I'll just put it here instead of emailing it:
> http://oss.oracle.com/~rdunlap/doc/cry32.out
>
> --
> ~Randy
> *** Remember to use Documentation/SubmitChecklist when testing your code ***
On 11/29/10 12:02, Mathias Krause wrote:
> On 29.11.2010, 20:54 Randy Dunlap wrote:
>> On 11/29/10 11:45, Mathias Krause wrote:
>>> On 29.11.2010, 20:31 Randy Dunlap wrote:
>>>> On 11/29/10 11:21, Mathias Krause wrote:
>>>>> On 29.11.2010, 19:54 Randy Dunlap wrote:
>>>>>> On 11/29/10 10:26, Mathias Krause wrote:
>>>>>>> On 29.11.2010, 17:31 Randy Dunlap wrote:
>>>>>>>> On Mon, 29 Nov 2010 14:03:35 +1100 Stephen Rothwell wrote:
>>>>>>>>
>>>>>>>>> Hi all,
>>>>>>>>>
>>>>>>>>> Changes since 20101126:
>>>>>>>>
>>>>>>>>
>>>>>>>> on i386 builds, I get tons of these (and more) errors:
>>>>>>>>
>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:841: Error: bad register name `%r12'
>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:842: Error: bad register name `%r13'
>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:843: Error: bad register name `%r14'
>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:844: Error: bad register name `%rsp'
>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:849: Error: bad register name `%rsp'
>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:850: Error: bad register name `%rsp'
>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:851: Error: bad register name `%r9'
>>>>>>>>
>>>>>>>> even though the kernel .config file says:
>>>>>>>>
>>>>>>>> CONFIG_CRYPTO_AES=m
>>>>>>>> CONFIG_CRYPTO_AES_586=m
>>>>>>>> CONFIG_CRYPTO_AES_NI_INTEL=m
>>>>>>>>
>>>>>>>> Should arch/x86/crypto/aesni-intel_asm.S be testing
>>>>>>>> #ifdef CONFIG_X86_64
>>>>>>>> instead of
>>>>>>>> #ifdef __x86_64__
>>>>>>>> or does that not matter?
>>>>>>>>
>>>>>>>> or is this a toolchain issue?
>>>>>>>
>>>>>>> Well, __x86_64__ should be a build-in define of the compiler while
>>>>>>> CONFIG_X86_64 is defined for 64 bit builds in include/generated/autoconf.h.
>>>>>>> So by using the latter we should be on the safe side but if your compiler
>>>>>>> defines __x86_64__ for 32-bit builds it's simply broken. Also git grep
>>>>>>> showed quite a few more places using __x86_64__ so those would miscompile on
>>>>>>> your toolchain, too.
>>>>>>>
>>>>>>> But it looks like linux-next is just missing
>>>>>>> 559ad0ff1368baea14dbc3207d55b02bd69bda4b from Herbert's git repo at
>>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git.
>>>>>>> That should fix the build issue.
>>>>>>
>>>>>> The build problem still happens when that patch is applied.
>>>>>
>>>>> That's weird. So it must be something with your toolchain.
>>>>> Can you please post the output of the following commands?:
>>>>>
>>>>> $ touch /tmp/null.c; cc -m32 -dD -E /tmp/null.c | grep -E 'x86|i.86'
>>>>
>>>> #define __i386 1
>>>> #define __i386__ 1
>>>> #define i386 1
>>>> #define __i586 1
>>>> #define __i586__ 1
>>>>
>>>>> $ touch /tmp/null.c; cc -m64 -dD -E /tmp/null.c | grep -E 'x86|i.86'
>>>>
>>>> #define __x86_64 1
>>>> #define __x86_64__ 1
>>>>
>>>> So that's not the problem... and the patch below didn't help.
>>>
>>> That's odd. The output of the commands looks good so the x86-64 specific code
>>> should be left out for 32-bit builds. :/
>>>
>>>> Sorry that I even asked about that. What next?
>>>
>>> Can you please post the full error message. Meanwhile I'm checking out a
>>> linux-next tree, trying to reproduce your problem.
>>>
>>
>> I just built with "make V=1" to see the full commands that are used, but
>> that didn't help me either:
>>
>> gcc -Wp,-MD,arch/x86/crypto/.aesni-intel_asm.o.d -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/4.4.1/include -I/lnx/src/NEXT/linux-next-20101129/arch/x86/include -Iinclude -I/lnx/src/NEXT/linux-next-20101129/include -include include/generated/autoconf.h -D__KERNEL__ -D__ASSEMBLY__ -m32 -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DMODULE -c -o arch/x86/crypto/aesni-intel_asm.o /lnx/src/NEXT/linux-next-20101129/arch/x86/crypto/aesni-intel_asm.S
>>
>>
>> There are 2945 lines like this:
>>
>> linux-next-20101129/arch/x86/crypto/aesni-intel_asm.S:841: Error: bad register name `%r12'
>
> Well, in my tree (linux-next + 559ad0ff) line 841 is a comment. Albeit without
> 559ad0ff it's a 'push %r12'. So maybe you should apply the patch just once
> more to be sure. ;)
Touche.
What does that patch have to do with aesni-intel??
I'm using the linux-next tarball of 20111129.
However, your s/__x86_64__/CONFIG_X86_64/ patch was applied, so I dropped it.
new output file:
http://oss.oracle.com/~rdunlap/doc/cry4.out
>> It's around 311 KB, so I'll just put it here instead of emailing it:
>> http://oss.oracle.com/~rdunlap/doc/cry32.out
--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
On 29.11.2010, 21:11 Randy Dunlap wrote:
> On 11/29/10 12:02, Mathias Krause wrote:
>> On 29.11.2010, 20:54 Randy Dunlap wrote:
>>> On 11/29/10 11:45, Mathias Krause wrote:
>>>> On 29.11.2010, 20:31 Randy Dunlap wrote:
>>>>> On 11/29/10 11:21, Mathias Krause wrote:
>>>>>> On 29.11.2010, 19:54 Randy Dunlap wrote:
>>>>>>> On 11/29/10 10:26, Mathias Krause wrote:
>>>>>>>> On 29.11.2010, 17:31 Randy Dunlap wrote:
>>>>>>>>> On Mon, 29 Nov 2010 14:03:35 +1100 Stephen Rothwell wrote:
>>>>>>>>>
>>>>>>>>>> Hi all,
>>>>>>>>>>
>>>>>>>>>> Changes since 20101126:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> on i386 builds, I get tons of these (and more) errors:
>>>>>>>>>
>>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:841: Error: bad register name `%r12'
>>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:842: Error: bad register name `%r13'
>>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:843: Error: bad register name `%r14'
>>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:844: Error: bad register name `%rsp'
>>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:849: Error: bad register name `%rsp'
>>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:850: Error: bad register name `%rsp'
>>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:851: Error: bad register name `%r9'
>>>>>>>>>
>>>>>>>>> even though the kernel .config file says:
>>>>>>>>>
>>>>>>>>> CONFIG_CRYPTO_AES=m
>>>>>>>>> CONFIG_CRYPTO_AES_586=m
>>>>>>>>> CONFIG_CRYPTO_AES_NI_INTEL=m
>>>>>>>>>
>>>>>>>>> Should arch/x86/crypto/aesni-intel_asm.S be testing
>>>>>>>>> #ifdef CONFIG_X86_64
>>>>>>>>> instead of
>>>>>>>>> #ifdef __x86_64__
>>>>>>>>> or does that not matter?
>>>>>>>>>
>>>>>>>>> or is this a toolchain issue?
>>>>>>>>
>>>>>>>> Well, __x86_64__ should be a build-in define of the compiler while
>>>>>>>> CONFIG_X86_64 is defined for 64 bit builds in include/generated/autoconf.h.
>>>>>>>> So by using the latter we should be on the safe side but if your compiler
>>>>>>>> defines __x86_64__ for 32-bit builds it's simply broken. Also git grep
>>>>>>>> showed quite a few more places using __x86_64__ so those would miscompile on
>>>>>>>> your toolchain, too.
>>>>>>>>
>>>>>>>> But it looks like linux-next is just missing
>>>>>>>> 559ad0ff1368baea14dbc3207d55b02bd69bda4b from Herbert's git repo at
>>>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git.
>>>>>>>> That should fix the build issue.
>>>>>>>
>>>>>>> The build problem still happens when that patch is applied.
>>>>>>
>>>>>> That's weird. So it must be something with your toolchain.
>>>>>> Can you please post the output of the following commands?:
>>>>>>
>>>>>> $ touch /tmp/null.c; cc -m32 -dD -E /tmp/null.c | grep -E 'x86|i.86'
>>>>>
>>>>> #define __i386 1
>>>>> #define __i386__ 1
>>>>> #define i386 1
>>>>> #define __i586 1
>>>>> #define __i586__ 1
>>>>>
>>>>>> $ touch /tmp/null.c; cc -m64 -dD -E /tmp/null.c | grep -E 'x86|i.86'
>>>>>
>>>>> #define __x86_64 1
>>>>> #define __x86_64__ 1
>>>>>
>>>>> So that's not the problem... and the patch below didn't help.
>>>>
>>>> That's odd. The output of the commands looks good so the x86-64 specific code
>>>> should be left out for 32-bit builds. :/
>>>>
>>>>> Sorry that I even asked about that. What next?
>>>>
>>>> Can you please post the full error message. Meanwhile I'm checking out a
>>>> linux-next tree, trying to reproduce your problem.
>>>>
>>>
>>> I just built with "make V=1" to see the full commands that are used, but
>>> that didn't help me either:
>>>
>>> gcc -Wp,-MD,arch/x86/crypto/.aesni-intel_asm.o.d -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/4.4.1/include -I/lnx/src/NEXT/linux-next-20101129/arch/x86/include -Iinclude -I/lnx/src/NEXT/linux-next-20101129/include -include include/generated/autoconf.h -D__KERNEL__ -D__ASSEMBLY__ -m32 -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DMODULE -c -o arch/x86/crypto/aesni-intel_asm.o /lnx/src/NEXT/linux-next-20101129/arch/x86/crypto/aesni-intel_asm.S
>>>
>>>
>>> There are 2945 lines like this:
>>>
>>> linux-next-20101129/arch/x86/crypto/aesni-intel_asm.S:841: Error: bad register name `%r12'
>>
>> Well, in my tree (linux-next + 559ad0ff) line 841 is a comment. Albeit without
>> 559ad0ff it's a 'push %r12'. So maybe you should apply the patch just once
>> more to be sure. ;)
>
> Touche.
> What does that patch have to do with aesni-intel??
The description should be clear enough: "crypto: aesni-intel - Fixed build error
on x86-32".
Here is the link to the patch: <http://git.kernel.org/?p=linux/kernel/git/herbert/cryptodev-2.6.git;a=patch;h=559ad0ff1368baea14dbc3207d55b02bd69bda4b>. Please apply it on
top of your linux-next build.
> I'm using the linux-next tarball of 20111129.
> However, your s/__x86_64__/CONFIG_X86_64/ patch was applied, so I dropped it.
Well I doubt it. The patch was made on top of 559ad0ff so it should have failed
to apply in your tree since obviously 559ad0ff is missing.
> new output file:
> http://oss.oracle.com/~rdunlap/doc/cry4.out
Same bug: 559ad0ff is still missing. Please apply the patch from the link above.
On 11/29/10 12:21, Mathias Krause wrote:
> On 29.11.2010, 21:11 Randy Dunlap wrote:
>> On 11/29/10 12:02, Mathias Krause wrote:
>>> On 29.11.2010, 20:54 Randy Dunlap wrote:
>>>> On 11/29/10 11:45, Mathias Krause wrote:
>>>>> On 29.11.2010, 20:31 Randy Dunlap wrote:
>>>>>> On 11/29/10 11:21, Mathias Krause wrote:
>>>>>>> On 29.11.2010, 19:54 Randy Dunlap wrote:
>>>>>>>> On 11/29/10 10:26, Mathias Krause wrote:
>>>>>>>>> On 29.11.2010, 17:31 Randy Dunlap wrote:
>>>>>>>>>> On Mon, 29 Nov 2010 14:03:35 +1100 Stephen Rothwell wrote:
>>>>>>>>>>
>>>>>>>>>>> Hi all,
>>>>>>>>>>>
>>>>>>>>>>> Changes since 20101126:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> on i386 builds, I get tons of these (and more) errors:
>>>>>>>>>>
>>>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:841: Error: bad register name `%r12'
>>>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:842: Error: bad register name `%r13'
>>>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:843: Error: bad register name `%r14'
>>>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:844: Error: bad register name `%rsp'
>>>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:849: Error: bad register name `%rsp'
>>>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:850: Error: bad register name `%rsp'
>>>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:851: Error: bad register name `%r9'
>>>>>>>>>>
>>>>>>>>>> even though the kernel .config file says:
>>>>>>>>>>
>>>>>>>>>> CONFIG_CRYPTO_AES=m
>>>>>>>>>> CONFIG_CRYPTO_AES_586=m
>>>>>>>>>> CONFIG_CRYPTO_AES_NI_INTEL=m
>>>>>>>>>>
>>>>>>>>>> Should arch/x86/crypto/aesni-intel_asm.S be testing
>>>>>>>>>> #ifdef CONFIG_X86_64
>>>>>>>>>> instead of
>>>>>>>>>> #ifdef __x86_64__
>>>>>>>>>> or does that not matter?
>>>>>>>>>>
>>>>>>>>>> or is this a toolchain issue?
>>>>>>>>>
>>>>>>>>> Well, __x86_64__ should be a build-in define of the compiler while
>>>>>>>>> CONFIG_X86_64 is defined for 64 bit builds in include/generated/autoconf.h.
>>>>>>>>> So by using the latter we should be on the safe side but if your compiler
>>>>>>>>> defines __x86_64__ for 32-bit builds it's simply broken. Also git grep
>>>>>>>>> showed quite a few more places using __x86_64__ so those would miscompile on
>>>>>>>>> your toolchain, too.
>>>>>>>>>
>>>>>>>>> But it looks like linux-next is just missing
>>>>>>>>> 559ad0ff1368baea14dbc3207d55b02bd69bda4b from Herbert's git repo at
>>>>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git.
>>>>>>>>> That should fix the build issue.
>>>>>>>>
>>>>>>>> The build problem still happens when that patch is applied.
>>>>>>>
>>>>>>> That's weird. So it must be something with your toolchain.
>>>>>>> Can you please post the output of the following commands?:
>>>>>>>
>>>>>>> $ touch /tmp/null.c; cc -m32 -dD -E /tmp/null.c | grep -E 'x86|i.86'
>>>>>>
>>>>>> #define __i386 1
>>>>>> #define __i386__ 1
>>>>>> #define i386 1
>>>>>> #define __i586 1
>>>>>> #define __i586__ 1
>>>>>>
>>>>>>> $ touch /tmp/null.c; cc -m64 -dD -E /tmp/null.c | grep -E 'x86|i.86'
>>>>>>
>>>>>> #define __x86_64 1
>>>>>> #define __x86_64__ 1
>>>>>>
>>>>>> So that's not the problem... and the patch below didn't help.
>>>>>
>>>>> That's odd. The output of the commands looks good so the x86-64 specific code
>>>>> should be left out for 32-bit builds. :/
>>>>>
>>>>>> Sorry that I even asked about that. What next?
>>>>>
>>>>> Can you please post the full error message. Meanwhile I'm checking out a
>>>>> linux-next tree, trying to reproduce your problem.
>>>>>
>>>>
>>>> I just built with "make V=1" to see the full commands that are used, but
>>>> that didn't help me either:
>>>>
>>>> gcc -Wp,-MD,arch/x86/crypto/.aesni-intel_asm.o.d -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/4.4.1/include -I/lnx/src/NEXT/linux-next-20101129/arch/x86/include -Iinclude -I/lnx/src/NEXT/linux-next-20101129/include -include include/generated/autoconf.h -D__KERNEL__ -D__ASSEMBLY__ -m32 -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DMODULE -c -o arch/x86/crypto/aesni-intel_asm.o /lnx/src/NEXT/linux-next-20101129/arch/x86/crypto/aesni-intel_asm.S
>>>>
>>>>
>>>> There are 2945 lines like this:
>>>>
>>>> linux-next-20101129/arch/x86/crypto/aesni-intel_asm.S:841: Error: bad register name `%r12'
>>>
>>> Well, in my tree (linux-next + 559ad0ff) line 841 is a comment. Albeit without
>>> 559ad0ff it's a 'push %r12'. So maybe you should apply the patch just once
>>> more to be sure. ;)
>>
>> Touche.
>> What does that patch have to do with aesni-intel??
>
> The description should be clear enough: "crypto: aesni-intel - Fixed build error
> on x86-32".
> Here is the link to the patch: <http://git.kernel.org/?p=linux/kernel/git/herbert/cryptodev-2.6.git;a=patch;h=559ad0ff1368baea14dbc3207d55b02bd69bda4b>. Please apply it on
> top of your linux-next build.
>
>> I'm using the linux-next tarball of 20111129.
>> However, your s/__x86_64__/CONFIG_X86_64/ patch was applied, so I dropped it.
>
> Well I doubt it. The patch was made on top of 559ad0ff so it should have failed
> to apply in your tree since obviously 559ad0ff is missing.
>
>> new output file:
>> http://oss.oracle.com/~rdunlap/doc/cry4.out
>
> Same bug: 559ad0ff is still missing. Please apply the patch from the link above.
Thanks for persisting/continuing with me.
I apologize, I had applied the most recent patch in Herbert's cryptodev repo,
not the one that you referred me to.
Yes, the build is now fixed.
--
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
On 29.11.2010, 21:37 Randy Dunlap wrote:
> On 11/29/10 12:21, Mathias Krause wrote:
>> On 29.11.2010, 21:11 Randy Dunlap wrote:
>>> On 11/29/10 12:02, Mathias Krause wrote:
>>>> On 29.11.2010, 20:54 Randy Dunlap wrote:
>>>>> On 11/29/10 11:45, Mathias Krause wrote:
>>>>>> On 29.11.2010, 20:31 Randy Dunlap wrote:
>>>>>>> On 11/29/10 11:21, Mathias Krause wrote:
>>>>>>>> On 29.11.2010, 19:54 Randy Dunlap wrote:
>>>>>>>>> On 11/29/10 10:26, Mathias Krause wrote:
>>>>>>>>>> On 29.11.2010, 17:31 Randy Dunlap wrote:
>>>>>>>>>>> On Mon, 29 Nov 2010 14:03:35 +1100 Stephen Rothwell wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>
>>>>>>>>>>>> Changes since 20101126:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> on i386 builds, I get tons of these (and more) errors:
>>>>>>>>>>>
>>>>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:841: Error: bad register name `%r12'
>>>>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:842: Error: bad register name `%r13'
>>>>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:843: Error: bad register name `%r14'
>>>>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:844: Error: bad register name `%rsp'
>>>>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:849: Error: bad register name `%rsp'
>>>>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:850: Error: bad register name `%rsp'
>>>>>>>>>>> arch/x86/crypto/aesni-intel_asm.S:851: Error: bad register name `%r9'
>>>>>>>>>>>
>>>>>>>>>>> even though the kernel .config file says:
>>>>>>>>>>>
>>>>>>>>>>> CONFIG_CRYPTO_AES=m
>>>>>>>>>>> CONFIG_CRYPTO_AES_586=m
>>>>>>>>>>> CONFIG_CRYPTO_AES_NI_INTEL=m
>>>>>>>>>>>
>>>>>>>>>>> Should arch/x86/crypto/aesni-intel_asm.S be testing
>>>>>>>>>>> #ifdef CONFIG_X86_64
>>>>>>>>>>> instead of
>>>>>>>>>>> #ifdef __x86_64__
>>>>>>>>>>> or does that not matter?
>>>>>>>>>>>
>>>>>>>>>>> or is this a toolchain issue?
>>>>>>>>>>
>>>>>>>>>> Well, __x86_64__ should be a build-in define of the compiler while
>>>>>>>>>> CONFIG_X86_64 is defined for 64 bit builds in include/generated/autoconf.h.
>>>>>>>>>> So by using the latter we should be on the safe side but if your compiler
>>>>>>>>>> defines __x86_64__ for 32-bit builds it's simply broken. Also git grep
>>>>>>>>>> showed quite a few more places using __x86_64__ so those would miscompile on
>>>>>>>>>> your toolchain, too.
>>>>>>>>>>
>>>>>>>>>> But it looks like linux-next is just missing
>>>>>>>>>> 559ad0ff1368baea14dbc3207d55b02bd69bda4b from Herbert's git repo at
>>>>>>>>>> git://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git.
>>>>>>>>>> That should fix the build issue.
>>>>>>>>>
>>>>>>>>> The build problem still happens when that patch is applied.
>>>>>>>>
>>>>>>>> That's weird. So it must be something with your toolchain.
>>>>>>>> Can you please post the output of the following commands?:
>>>>>>>>
>>>>>>>> $ touch /tmp/null.c; cc -m32 -dD -E /tmp/null.c | grep -E 'x86|i.86'
>>>>>>>
>>>>>>> #define __i386 1
>>>>>>> #define __i386__ 1
>>>>>>> #define i386 1
>>>>>>> #define __i586 1
>>>>>>> #define __i586__ 1
>>>>>>>
>>>>>>>> $ touch /tmp/null.c; cc -m64 -dD -E /tmp/null.c | grep -E 'x86|i.86'
>>>>>>>
>>>>>>> #define __x86_64 1
>>>>>>> #define __x86_64__ 1
>>>>>>>
>>>>>>> So that's not the problem... and the patch below didn't help.
>>>>>>
>>>>>> That's odd. The output of the commands looks good so the x86-64 specific code
>>>>>> should be left out for 32-bit builds. :/
>>>>>>
>>>>>>> Sorry that I even asked about that. What next?
>>>>>>
>>>>>> Can you please post the full error message. Meanwhile I'm checking out a
>>>>>> linux-next tree, trying to reproduce your problem.
>>>>>>
>>>>>
>>>>> I just built with "make V=1" to see the full commands that are used, but
>>>>> that didn't help me either:
>>>>>
>>>>> gcc -Wp,-MD,arch/x86/crypto/.aesni-intel_asm.o.d -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/4.4.1/include -I/lnx/src/NEXT/linux-next-20101129/arch/x86/include -Iinclude -I/lnx/src/NEXT/linux-next-20101129/include -include include/generated/autoconf.h -D__KERNEL__ -D__ASSEMBLY__ -m32 -DCONFIG_AS_CFI=1 -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DMODULE -c -o arch/x86/crypto/aesni-intel_asm.o /lnx/src/NEXT/linux-next-20101129/arch/x86/crypto/aesni-intel_asm.S
>>>>>
>>>>>
>>>>> There are 2945 lines like this:
>>>>>
>>>>> linux-next-20101129/arch/x86/crypto/aesni-intel_asm.S:841: Error: bad register name `%r12'
>>>>
>>>> Well, in my tree (linux-next + 559ad0ff) line 841 is a comment. Albeit without
>>>> 559ad0ff it's a 'push %r12'. So maybe you should apply the patch just once
>>>> more to be sure. ;)
>>>
>>> Touche.
>>> What does that patch have to do with aesni-intel??
>>
>> The description should be clear enough: "crypto: aesni-intel - Fixed build error
>> on x86-32".
>> Here is the link to the patch: <http://git.kernel.org/?p=linux/kernel/git/herbert/cryptodev-2.6.git;a=patch;h=559ad0ff1368baea14dbc3207d55b02bd69bda4b>. Please apply it on
>> top of your linux-next build.
>>
>>> I'm using the linux-next tarball of 20111129.
>>> However, your s/__x86_64__/CONFIG_X86_64/ patch was applied, so I dropped it.
>>
>> Well I doubt it. The patch was made on top of 559ad0ff so it should have failed
>> to apply in your tree since obviously 559ad0ff is missing.
>>
>>> new output file:
>>> http://oss.oracle.com/~rdunlap/doc/cry4.out
>>
>> Same bug: 559ad0ff is still missing. Please apply the patch from the link above.
>
> Thanks for persisting/continuing with me.
> I apologize, I had applied the most recent patch in Herbert's cryptodev repo,
> not the one that you referred me to.
>
> Yes, the build is now fixed.
Great! Have fun with your new AESNI-accelerated crypto :)