From: Randy Dunlap <randy.dunlap@oracle.com>
To: Mathias Krause <minipli@googlemail.com>
Cc: Herbert Xu <herbert@gondor.hengli.com.au>,
Stephen Rothwell <sfr@canb.auug.org.au>,
Huang Ying <ying.huang@intel.com>,
Vinodh Gopal <vinodh.gopal@intel.com>,
linux-next@vger.kernel.org, LKML <linux-kernel@vger.kernel.org>,
linux-crypto@vger.kernel.org
Subject: Re: linux-next: Tree for November 29 (aesni-intel)
Date: Mon, 29 Nov 2010 11:31:58 -0800 [thread overview]
Message-ID: <4CF3FFAE.40906@oracle.com> (raw)
In-Reply-To: <1291058505-9384-1-git-send-email-minipli@googlemail.com>
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 <minipli@googlemail.com>
> ---
> 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 ***
next prev parent reply other threads:[~2010-11-29 19:31 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-29 3:03 linux-next: Tree for November 29 Stephen Rothwell
2010-11-29 9:47 ` Zimny Lech
2010-11-29 14:57 ` Herbert Xu
2010-11-29 16:12 ` Randy Dunlap
2010-11-29 18:53 ` Zimny Lech
2010-11-29 13:18 ` Zimny Lech
2010-11-29 16:31 ` linux-next: Tree for November 29 (aesni-intel) Randy Dunlap
2010-11-29 18:26 ` Mathias Krause
2010-11-29 18:54 ` Randy Dunlap
2010-11-29 19:21 ` Mathias Krause
2010-11-29 19:31 ` Randy Dunlap [this message]
2010-11-29 19:45 ` Mathias Krause
2010-11-29 19:54 ` Randy Dunlap
2010-11-29 20:02 ` Mathias Krause
2010-11-29 20:11 ` Randy Dunlap
2010-11-29 20:21 ` Mathias Krause
2010-11-29 20:37 ` Randy Dunlap
2010-11-29 20:46 ` Mathias Krause
2010-11-29 19:52 ` Mathias Krause
2010-11-29 19:56 ` Randy Dunlap
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4CF3FFAE.40906@oracle.com \
--to=randy.dunlap@oracle.com \
--cc=herbert@gondor.hengli.com.au \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=minipli@googlemail.com \
--cc=sfr@canb.auug.org.au \
--cc=vinodh.gopal@intel.com \
--cc=ying.huang@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).