All of lore.kernel.org
 help / color / mirror / Atom feed
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 12:37:15 -0800	[thread overview]
Message-ID: <4CF40EFB.60008@oracle.com> (raw)
In-Reply-To: <41CA6D05-C836-4F43-8DD8-C7EA9948DACC@googlemail.com>

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 ***

  reply	other threads:[~2010-11-29 20:37 UTC|newest]

Thread overview: 24+ 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 14:57     ` Herbert Xu
2010-11-29 16:12     ` Randy Dunlap
2010-11-29 18:53     ` Zimny Lech
2010-11-29 18:53       ` Zimny Lech
2010-11-29 13:18 ` 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:21         ` Mathias Krause
2010-11-29 19:31         ` Randy Dunlap
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 [this message]
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=4CF40EFB.60008@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.