From: Mathias Krause <minipli@googlemail•com>
To: Randy Dunlap <randy.dunlap@oracle•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 20:45:39 +0100 [thread overview]
Message-ID: <45B80502-8597-4650-990F-F23B4FC751B8@googlemail.com> (raw)
In-Reply-To: <4CF3FFAE.40906@oracle.com>
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.
next prev parent reply other threads:[~2010-11-29 19:45 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
2010-11-29 19:45 ` Mathias Krause [this message]
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=45B80502-8597-4650-990F-F23B4FC751B8@googlemail.com \
--to=minipli@googlemail$(echo .)com \
--cc=herbert@gondor$(echo .)hengli.com.au \
--cc=linux-crypto@vger$(echo .)kernel.org \
--cc=linux-kernel@vger$(echo .)kernel.org \
--cc=linux-next@vger$(echo .)kernel.org \
--cc=randy.dunlap@oracle$(echo .)com \
--cc=sfr@canb$(echo .)auug.org.au \
--cc=vinodh.gopal@intel$(echo .)com \
--cc=ying.huang@intel$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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