linux-next: build failure after merge of the luto-misc tree

linux-next: build failure after merge of the luto-misc tree

[Stephen Rothwell]

Hi Andy,

After merging the luto-misc tree, today's linux-next build (x86_64
allmodconfig) failed like this:

In file included from arch/x86/include/uapi/asm/bitsperlong.h:10:0,
                 from include/uapi/asm-generic/int-ll64.h:11,
                 from include/uapi/asm-generic/types.h:6,  
                 from arch/x86/include/uapi/asm/types.h:4,
                 from tools/include/linux/types.h:9,
                 from include/uapi/linux/elf.h:4,
                 from arch/x86/entry/vdso/vdso2c.c:66:
tools/include/asm-generic/bitsperlong.h:32:2: error: #error Inconsistent word size. Check asm/bitsperlong.h
 #error Inconsistent word size. Check asm/bitsperlong.h
  ^

Caused by commit

  6436d4c1a83c ("x86/vdso: Fail the build if the vdso image has no dynamic section")

interacting with commit

  2a00f026a15d ("tools: Fix up BITS_PER_LONG setting")

from the tip tree.

I am not sure why 6436d4c1a83c does this ... maybe it just causes
arch/x86/entry/vdso/vdso2c.c to be rebuilt?

I applied this partial revert of the latter commit:

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 15 Jul 2016 16:58:25 +1000
Subject: [PATCH] tools: partial revert of 2a00f026a15d "tools: Fix up
 BITS_PER_LONG setting"

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 tools/include/asm-generic/bitsperlong.h | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/tools/include/asm-generic/bitsperlong.h b/tools/include/asm-generic/bitsperlong.h
index cfd661c6fc17..cb047bd03b69 100644
--- a/tools/include/asm-generic/bitsperlong.h
+++ b/tools/include/asm-generic/bitsperlong.h
@@ -28,7 +28,11 @@
 #define BITS_PER_LONG 32
 #endif /* CONFIG_64BIT */
 
-#if BITS_PER_LONG != __BITS_PER_LONG
+/*
+ * FIXME: The check currently breaks x86-64 build, so it's
+ * temporarily disabled. Please fix x86-64 and reenable
+ */
+#if 0 && BITS_PER_LONG != __BITS_PER_LONG
 #error Inconsistent word size. Check asm/bitsperlong.h
 #endif
 
-- 
2.8.1

-- 
Cheers,
Stephen Rothwell

Re: linux-next: build failure after merge of the luto-misc tree

[Peter Zijlstra]

On Fri, Jul 15, 2016 at 05:06:54PM +1000, Stephen Rothwell wrote:
> interacting with commit
> 
>   2a00f026a15d ("tools: Fix up BITS_PER_LONG setting")
> 
> from the tip tree.

Yuck.. that thing is horrid :/

What's wrong with so?

And if you really want to retain CONFIG_64BIT (because other headers
might want it, and they currently do not) then do something like:

#ifdef __LP64__
#define CONFIG_64BIT
#else
#define CONFIG_32BIT
#endif

All GCC versions I checked have __CHAR_BIT__ and __SIZEOF_LONG__.

(and I checked most everything from 4.4 - 6.1)


diff --git a/tools/include/asm-generic/bitsperlong.h b/tools/include/asm-generic/bitsperlong.h
index cfd661c6fc17..4b4c91b0f042 100644
--- a/tools/include/asm-generic/bitsperlong.h
+++ b/tools/include/asm-generic/bitsperlong.h
@@ -3,37 +3,6 @@
 
 #include <uapi/asm-generic/bitsperlong.h>
 
-/*
- * In the kernel, where this file comes from, we can rely on CONFIG_64BIT,
- * here we have to make amends with what the various compilers provides us
- * to figure out if we're on a 64-bit machine...
- */
-#ifdef __SIZEOF_LONG__
-# if __SIZEOF_LONG__ == 8
-#  define CONFIG_64BIT
-# endif
-#else
-# ifdef __WORDSIZE
-#  if __WORDSIZE == 64
-#   define CONFIG_64BIT
-#  endif
-# else
-#  error Failed to determine BITS_PER_LONG value
-# endif
-#endif
-
-#ifdef CONFIG_64BIT
-#define BITS_PER_LONG 64
-#else
-#define BITS_PER_LONG 32
-#endif /* CONFIG_64BIT */
-
-#if BITS_PER_LONG != __BITS_PER_LONG
-#error Inconsistent word size. Check asm/bitsperlong.h
-#endif
-
-#ifndef BITS_PER_LONG_LONG
-#define BITS_PER_LONG_LONG 64
-#endif
+#define BITS_PER_LONG (__CHAR_BIT__ * __SIZEOF_LONG__)
 
 #endif /* __ASM_GENERIC_BITS_PER_LONG */

Re: linux-next: build failure after merge of the luto-misc tree

[Peter Zijlstra]

On Fri, Jul 15, 2016 at 09:22:43AM +0200, Peter Zijlstra wrote:
> On Fri, Jul 15, 2016 at 05:06:54PM +1000, Stephen Rothwell wrote:
> > interacting with commit
> > 
> >   2a00f026a15d ("tools: Fix up BITS_PER_LONG setting")
> > 
> > from the tip tree.
> 
> Yuck.. that thing is horrid :/
> 
> What's wrong with so?
> 
> And if you really want to retain CONFIG_64BIT (because other headers
> might want it, and they currently do not) then do something like:
> 
> #ifdef __LP64__
> #define CONFIG_64BIT
> #else
> #define CONFIG_32BIT
> #endif
> 
> All GCC versions I checked have __CHAR_BIT__ and __SIZEOF_LONG__.
> 
> (and I checked most everything from 4.4 - 6.1)

clang-3.8 also defines all three of those, and I don't consider that a
usable compiler as it doesn't even build a kernel.

Re: linux-next: build failure after merge of the luto-misc tree

[Arnaldo Carvalho de Melo]

Em Fri, Jul 15, 2016 at 09:31:19AM +0200, Peter Zijlstra escreveu:
> On Fri, Jul 15, 2016 at 09:22:43AM +0200, Peter Zijlstra wrote:
> > On Fri, Jul 15, 2016 at 05:06:54PM +1000, Stephen Rothwell wrote:
> > > interacting with commit
> > > 
> > >   2a00f026a15d ("tools: Fix up BITS_PER_LONG setting")
> > > 
> > > from the tip tree.
> > 
> > Yuck.. that thing is horrid :/
> > 
> > What's wrong with so?
> > 
> > And if you really want to retain CONFIG_64BIT (because other headers
> > might want it, and they currently do not) then do something like:
> > 
> > #ifdef __LP64__
> > #define CONFIG_64BIT
> > #else
> > #define CONFIG_32BIT
> > #endif
> > 
> > All GCC versions I checked have __CHAR_BIT__ and __SIZEOF_LONG__.
> > 
> > (and I checked most everything from 4.4 - 6.1)
> 
> clang-3.8 also defines all three of those, and I don't consider that a
> usable compiler as it doesn't even build a kernel.

I was trying to have that file as close to the kernel as possible, but
I'll try building with your patch in my test rig, lets see if one of the
dozens of distros/releases barf at that...

- Arnaldo

Re: linux-next: build failure after merge of the luto-misc tree

[Arnaldo Carvalho de Melo]

Em Fri, Jul 15, 2016 at 12:09:03PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Fri, Jul 15, 2016 at 09:31:19AM +0200, Peter Zijlstra escreveu:
> > On Fri, Jul 15, 2016 at 09:22:43AM +0200, Peter Zijlstra wrote:
> > > On Fri, Jul 15, 2016 at 05:06:54PM +1000, Stephen Rothwell wrote:
> > > > interacting with commit
> > > > 
> > > >   2a00f026a15d ("tools: Fix up BITS_PER_LONG setting")
> > > > 
> > > > from the tip tree.
> > > 
> > > Yuck.. that thing is horrid :/
> > > 
> > > What's wrong with so?
> > > 
> > > And if you really want to retain CONFIG_64BIT (because other headers
> > > might want it, and they currently do not) then do something like:
> > > 
> > > #ifdef __LP64__
> > > #define CONFIG_64BIT
> > > #else
> > > #define CONFIG_32BIT
> > > #endif
> > > 
> > > All GCC versions I checked have __CHAR_BIT__ and __SIZEOF_LONG__.
> > > 
> > > (and I checked most everything from 4.4 - 6.1)
> > 
> > clang-3.8 also defines all three of those, and I don't consider that a
> > usable compiler as it doesn't even build a kernel.
> 
> I was trying to have that file as close to the kernel as possible, but
> I'll try building with your patch in my test rig, lets see if one of the
> dozens of distros/releases barf at that...


Seems ok, but I'll reinstate this:

#if BITS_PER_LONG != __BITS_PER_LONG
#error Inconsistent word size. Check asm/bitsperlong.h
#endif

And now I'm rerunning these tests, that without the above check
produces:

# dm
alpine:3.4: Ok
android-ndk:r12b: Ok
centos:5: perf: Ok, objtool: FAIL   # But this one predates this patch, I'll fix it
centos:6: Ok
centos:7: Ok
debian:7: Ok
debian:8: Ok
debian:experimental: Ok
fedora:21: Ok
fedora:22: Ok
fedora:23: Ok
fedora:24: Ok
fedora:rawhide: Ok
opensuse:13.2: Ok
opensuse:42.1: Ok
ubuntu:14.04.4: Ok
ubuntu:15.10: Ok
ubuntu:16.04: Ok
#

- Arnaldo

Re: linux-next: build failure after merge of the luto-misc tree

[Peter Zijlstra]

On Fri, Jul 15, 2016 at 12:24:36PM -0300, Arnaldo Carvalho de Melo wrote:
> Seems ok, but I'll reinstate this:
> 
> #if BITS_PER_LONG != __BITS_PER_LONG
> #error Inconsistent word size. Check asm/bitsperlong.h
> #endif

Confuses me; why do we have two?

Why not then do:

#define BITS_PER_LONG __BITS_PER_LONG

and be done with it?

[PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree

[Arnaldo Carvalho de Melo]

Em Fri, Jul 15, 2016 at 12:24:36PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Fri, Jul 15, 2016 at 12:09:03PM -0300, Arnaldo Carvalho de Melo escreveu:
> > Em Fri, Jul 15, 2016 at 09:31:19AM +0200, Peter Zijlstra escreveu:
> > > On Fri, Jul 15, 2016 at 09:22:43AM +0200, Peter Zijlstra wrote:
> > > > All GCC versions I checked have __CHAR_BIT__ and __SIZEOF_LONG__.

> > > > (and I checked most everything from 4.4 - 6.1)

> > > clang-3.8 also defines all three of those, and I don't consider that a
> > > usable compiler as it doesn't even build a kernel.

> > I was trying to have that file as close to the kernel as possible, but
> > I'll try building with your patch in my test rig, lets see if one of the
> > dozens of distros/releases barf at that...

> Seems ok, but I'll reinstate this:

> #if BITS_PER_LONG != __BITS_PER_LONG
> #error Inconsistent word size. Check asm/bitsperlong.h
> #endif

> And now I'm rerunning these tests, that without the above check

Ok, same results, it works, queuing this one, ack? Stephen, does it work
for you?

commit a08cc3e6f7bb965672a3ff60f98d0dbbc5334ee7
Author: Peter Zijlstra <peterz@infradead.org>
Date:   Fri Jul 15 12:38:18 2016 -0300

    tools: Simplify BITS_PER_LONG define
    
    Do it using (__CHAR_BIT__ * __SIZEOF_LONG__), simpler, works everywhere,
    reduces the complexity by ditching CONFIG_64BIT, that was being
    synthesized from yet another set of defines, which proved fragile,
    breaking the build on linux-next for no obvious reasons.
    
    Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
    Signed-off-by: Peter Zijlstra <peterz@infradead.org>
    Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
    Cc: Andy Lutomirski <luto@amacapital.net>,
    Cc: H. Peter Anvin <hpa@zytor.com>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Link: http://lkml.kernel.org/r/20160715072243.GP30154@twins.programming.kicks-ass.net
    Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>

diff --git a/tools/include/asm-generic/bitsperlong.h b/tools/include/asm-generic/bitsperlong.h
index cfd661c6fc17..4c7a9ab42424 100644
--- a/tools/include/asm-generic/bitsperlong.h
+++ b/tools/include/asm-generic/bitsperlong.h
@@ -3,30 +3,7 @@
 
 #include <uapi/asm-generic/bitsperlong.h>
 
-/*
- * In the kernel, where this file comes from, we can rely on CONFIG_64BIT,
- * here we have to make amends with what the various compilers provides us
- * to figure out if we're on a 64-bit machine...
- */
-#ifdef __SIZEOF_LONG__
-# if __SIZEOF_LONG__ == 8
-#  define CONFIG_64BIT
-# endif
-#else
-# ifdef __WORDSIZE
-#  if __WORDSIZE == 64
-#   define CONFIG_64BIT
-#  endif
-# else
-#  error Failed to determine BITS_PER_LONG value
-# endif
-#endif
-
-#ifdef CONFIG_64BIT
-#define BITS_PER_LONG 64
-#else
-#define BITS_PER_LONG 32
-#endif /* CONFIG_64BIT */
+#define BITS_PER_LONG (__CHAR_BIT__ * __SIZEOF_LONG__)
 
 #if BITS_PER_LONG != __BITS_PER_LONG
 #error Inconsistent word size. Check asm/bitsperlong.h

Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree

[Peter Zijlstra]

On Fri, Jul 15, 2016 at 12:43:26PM -0300, Arnaldo Carvalho de Melo wrote:
> Ok, same results, it works, queuing this one, ack?

Sure. Although I'm still somewhat puzzled by the duplicated effort of
__BITS_PER_LONG and BITS_PER_LONG.

> commit a08cc3e6f7bb965672a3ff60f98d0dbbc5334ee7
> Author: Peter Zijlstra <peterz@infradead.org>
> Date:   Fri Jul 15 12:38:18 2016 -0300
> 
>     tools: Simplify BITS_PER_LONG define
>     
>     Do it using (__CHAR_BIT__ * __SIZEOF_LONG__), simpler, works everywhere,
>     reduces the complexity by ditching CONFIG_64BIT, that was being
>     synthesized from yet another set of defines, which proved fragile,
>     breaking the build on linux-next for no obvious reasons.

If you ever do need to introduce CONFIG_64BIT, __LP64__ seems like the
right symbol to use for it.

Re: linux-next: build failure after merge of the luto-misc tree

[Arnaldo Carvalho de Melo]

Em Fri, Jul 15, 2016 at 05:29:37PM +0200, Peter Zijlstra escreveu:
> On Fri, Jul 15, 2016 at 12:24:36PM -0300, Arnaldo Carvalho de Melo wrote:
> > Seems ok, but I'll reinstate this:
> > 
> > #if BITS_PER_LONG != __BITS_PER_LONG
> > #error Inconsistent word size. Check asm/bitsperlong.h
> > #endif
> 
> Confuses me; why do we have two?
> 
> Why not then do:
> 
> #define BITS_PER_LONG __BITS_PER_LONG
> 
> and be done with it?

Well, I just kept existing kernel practice, it uses __BITS_PER_LONG in
uapi files and BITS_PER_LONG elsewhere, since we copy stuff from the
kernel and check when it drifts using diff, I kept it like that so that
automation could point us when the tools/ copy drifted from the original
file.

- Arnaldo

Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree

[Arnaldo Carvalho de Melo]

Em Fri, Jul 15, 2016 at 05:49:30PM +0200, Peter Zijlstra escreveu:
> On Fri, Jul 15, 2016 at 12:43:26PM -0300, Arnaldo Carvalho de Melo wrote:
> > Ok, same results, it works, queuing this one, ack?
> 
> Sure. Although I'm still somewhat puzzled by the duplicated effort of
> __BITS_PER_LONG and BITS_PER_LONG.

Well, I also can't think of something to justify that, would have to dig
deeper to figure out why that duplication was introduced.

Thanks, will queue this one up and be done with it. For the moment. :-)

- Arnaldo
 
> > commit a08cc3e6f7bb965672a3ff60f98d0dbbc5334ee7
> > Author: Peter Zijlstra <peterz@infradead.org>
> > Date:   Fri Jul 15 12:38:18 2016 -0300
> > 
> >     tools: Simplify BITS_PER_LONG define
> >     
> >     Do it using (__CHAR_BIT__ * __SIZEOF_LONG__), simpler, works everywhere,
> >     reduces the complexity by ditching CONFIG_64BIT, that was being
> >     synthesized from yet another set of defines, which proved fragile,
> >     breaking the build on linux-next for no obvious reasons.
> 
> If you ever do need to introduce CONFIG_64BIT, __LP64__ seems like the
> right symbol to use for it.

Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree

[H. Peter Anvin]

On 07/15/16 09:28, Arnaldo Carvalho de Melo wrote:
> Em Fri, Jul 15, 2016 at 05:49:30PM +0200, Peter Zijlstra escreveu:
>> On Fri, Jul 15, 2016 at 12:43:26PM -0300, Arnaldo Carvalho de Melo wrote:
>>> Ok, same results, it works, queuing this one, ack?
>>
>> Sure. Although I'm still somewhat puzzled by the duplicated effort of
>> __BITS_PER_LONG and BITS_PER_LONG.
> 
> Well, I also can't think of something to justify that, would have to dig
> deeper to figure out why that duplication was introduced.
> 
> Thanks, will queue this one up and be done with it. For the moment. :-)
> 

I'm wondering if there are issues related to compat.

	-hpa

[tip:perf/core] tools: Simplify BITS_PER_LONG define

[tip-bot for Peter Zijlstra]

Commit-ID:  e81fcd43723d32e9c9dbb8e8d66f147b5b84256b
Gitweb:     http://git.kernel.org/tip/e81fcd43723d32e9c9dbb8e8d66f147b5b84256b
Author:     Peter Zijlstra <peterz@infradead.org>
AuthorDate: Fri, 15 Jul 2016 12:38:18 -0300
Committer:  Arnaldo Carvalho de Melo <acme@redhat.com>
CommitDate: Fri, 15 Jul 2016 17:26:41 -0300

tools: Simplify BITS_PER_LONG define

Do it using (__CHAR_BIT__ * __SIZEOF_LONG__), simpler, works everywhere,
reduces the complexity by ditching CONFIG_64BIT, that was being
synthesized from yet another set of defines, which proved fragile,
breaking the build on linux-next for no obvious reasons.

Committer Note:

Except on:

gcc version 4.1.2 20080704 (Red Hat 4.1.2-55)

Fallback to __WORDSIZE in that case...

Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Tested-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20160715072243.GP30154@twins.programming.kicks-ass.net
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
---
 tools/include/asm-generic/bitsperlong.h | 23 ++---------------------
 1 file changed, 2 insertions(+), 21 deletions(-)

diff --git a/tools/include/asm-generic/bitsperlong.h b/tools/include/asm-generic/bitsperlong.h
index cfd661c..45eca51 100644
--- a/tools/include/asm-generic/bitsperlong.h
+++ b/tools/include/asm-generic/bitsperlong.h
@@ -3,31 +3,12 @@
 
 #include <uapi/asm-generic/bitsperlong.h>
 
-/*
- * In the kernel, where this file comes from, we can rely on CONFIG_64BIT,
- * here we have to make amends with what the various compilers provides us
- * to figure out if we're on a 64-bit machine...
- */
 #ifdef __SIZEOF_LONG__
-# if __SIZEOF_LONG__ == 8
-#  define CONFIG_64BIT
-# endif
+#define BITS_PER_LONG (__CHAR_BIT__ * __SIZEOF_LONG__)
 #else
-# ifdef __WORDSIZE
-#  if __WORDSIZE == 64
-#   define CONFIG_64BIT
-#  endif
-# else
-#  error Failed to determine BITS_PER_LONG value
-# endif
+#define BITS_PER_LONG __WORDSIZE
 #endif
 
-#ifdef CONFIG_64BIT
-#define BITS_PER_LONG 64
-#else
-#define BITS_PER_LONG 32
-#endif /* CONFIG_64BIT */
-
 #if BITS_PER_LONG != __BITS_PER_LONG
 #error Inconsistent word size. Check asm/bitsperlong.h
 #endif

Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree

[Stephen Rothwell]

Hi Arnaldo,

On Fri, 15 Jul 2016 12:43:26 -0300 Arnaldo Carvalho de Melo <acme@redhat.com> wrote:
>
> Ok, same results, it works, queuing this one, ack? Stephen, does it work
> for you?

Sorry, no.  See my other email.

I am cross building (if that makes a difference).

-- 
Cheers,
Stephen Rothwell

Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree

[Andy Lutomirski]

On Sun, Jul 17, 2016 at 10:18 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Arnaldo,
>
> On Fri, 15 Jul 2016 12:43:26 -0300 Arnaldo Carvalho de Melo <acme@redhat.com> wrote:
>>
>> Ok, same results, it works, queuing this one, ack? Stephen, does it work
>> for you?
>
> Sorry, no.  See my other email.
>
> I am cross building (if that makes a difference).

I wonder if something's wrong with the way that hostprogs-y works if
the program includes kernel headers.

It's plausible that something like this:

https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=x86/vdso&id=424eb7848324efbfcffaf58b142db1a455a9628b

coupled with a change to make vdso2c or, more generally, hostprogs-y
use USERINCLUDE would help.

--Andy

Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree

[Arnaldo Carvalho de Melo]

Em Mon, Jul 18, 2016 at 01:04:34PM -0700, Andy Lutomirski escreveu:
> On Sun, Jul 17, 2016 at 10:18 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > On Fri, 15 Jul 2016 12:43:26 -0300 Arnaldo Carvalho de Melo <acme@redhat.com> wrote:

> >> Ok, same results, it works, queuing this one, ack? Stephen, does it work
> >> for you?

> > Sorry, no.  See my other email.
> >
> > I am cross building (if that makes a difference).

For me to try to reproduce the problem, yes, what is the environment?
Cross-compiling to what target?
 
> I wonder if something's wrong with the way that hostprogs-y works if
> the program includes kernel headers.
> 
> It's plausible that something like this:
> 
> https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=x86/vdso&id=424eb7848324efbfcffaf58b142db1a455a9628b
> 
> coupled with a change to make vdso2c or, more generally, hostprogs-y
> use USERINCLUDE would help.

There are still files outside tools/ that are being accessed by it, so,
yeah, this may have affected it, I'll try to do a final sweep untangling
this.

- Arnaldo

Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree

[Stephen Rothwell]

Hi Arnaldo,

On Mon, 18 Jul 2016 17:36:34 -0300 Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
>
> Em Mon, Jul 18, 2016 at 01:04:34PM -0700, Andy Lutomirski escreveu:
> > On Sun, Jul 17, 2016 at 10:18 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:  
> > > On Fri, 15 Jul 2016 12:43:26 -0300 Arnaldo Carvalho de Melo <acme@redhat.com> wrote:  
> 
> > >> Ok, same results, it works, queuing this one, ack? Stephen, does it work
> > >> for you?  
> 
> > > Sorry, no.  See my other email.
> > >
> > > I am cross building (if that makes a difference).  
> 
> For me to try to reproduce the problem, yes, what is the environment?
> Cross-compiling to what target?

I am using a x86_64 compiler (target) on powerpc64le (host).
Yesterday, the x86_64 allmodconfig build failed just after I merged the
tip tree (i.e. without the luto-misc tree being involved).  At that
point I have merged quite a few trees, though.  Also, I do not clean my
object tree between builds.  The compiler is v5.2.0 built from upstream
sources.

-- 
Cheers,
Stephen Rothwell

Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree

[Arnaldo Carvalho de Melo]

Em Tue, Jul 19, 2016 at 08:22:35AM +1000, Stephen Rothwell escreveu:
> Hi Arnaldo,
> 
> On Mon, 18 Jul 2016 17:36:34 -0300 Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
> >
> > Em Mon, Jul 18, 2016 at 01:04:34PM -0700, Andy Lutomirski escreveu:
> > > On Sun, Jul 17, 2016 at 10:18 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:  
> > > > On Fri, 15 Jul 2016 12:43:26 -0300 Arnaldo Carvalho de Melo <acme@redhat.com> wrote:  
> > 
> > > >> Ok, same results, it works, queuing this one, ack? Stephen, does it work
> > > >> for you?  
> > 
> > > > Sorry, no.  See my other email.
> > > >
> > > > I am cross building (if that makes a difference).  
> > 
> > For me to try to reproduce the problem, yes, what is the environment?
> > Cross-compiling to what target?
> 
> I am using a x86_64 compiler (target) on powerpc64le (host).
> Yesterday, the x86_64 allmodconfig build failed just after I merged the
> tip tree (i.e. without the luto-misc tree being involved).  At that
> point I have merged quite a few trees, though.  Also, I do not clean my
> object tree between builds.  The compiler is v5.2.0 built from upstream
> sources.

Ok, one of the possible reasons was for tools/{include,lib,perf,objtool}
code to be including code directly from the kernel, and that was still
the case for some headers, I fixed those and pushed to Ingo now, if he
pulls lets see if this fixes things.

- Arnaldo

Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree

[Stephen Rothwell]

Hi Arnaldo,

On Mon, 18 Jul 2016 20:41:32 -0300 Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
>
> Ok, one of the possible reasons was for tools/{include,lib,perf,objtool}
> code to be including code directly from the kernel, and that was still
> the case for some headers, I fixed those and pushed to Ingo now, if he
> pulls lets see if this fixes things.

If you have a single patch (or few) relative to yesterday's tip tree,
please send it to me as well and I will apply it as a fix patch if Ingo
doesn't get to pulling in time.

-- 
Cheers,
Stephen Rothwell

Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree

[Arnaldo Carvalho de Melo]

Em Tue, Jul 19, 2016 at 10:26:29AM +1000, Stephen Rothwell escreveu:
> On Mon, 18 Jul 2016 20:41:32 -0300 Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
> > Ok, one of the possible reasons was for tools/{include,lib,perf,objtool}
> > code to be including code directly from the kernel, and that was still
> > the case for some headers, I fixed those and pushed to Ingo now, if he
> > pulls lets see if this fixes things.
 
> If you have a single patch (or few) relative to yesterday's tip tree,
> please send it to me as well and I will apply it as a fix patch if Ingo
> doesn't get to pulling in time.

[acme@jouet linux]$ git log --pretty=oneline  9fcfcdf3c7b613c0d9536f57587456411b8a4e33..ae3c14a028ed10552803b68276b6833295ba18cf 
ae3c14a028ed10552803b68276b6833295ba18cf tools: Copy linux/{hash,poison}.h and check for drift
3aa0042769313b720142c0ef8514dac389e14ebe perf tools: Remove include/linux/list.h from perf's MANIFEST
de1e17b1d0c81be472039798698b517c8a68b516 tools: Copy the bitops files accessed from the kernel and check for drift
ad430729ae00dd63f7dcadbeb638e589bc03b5a3 Remove: kernel unistd*h files from perf's MANIFEST, not used
e0643c4e9fdb2e77ab83ca596460e2c9c15728aa perf tools: Remove tools/perf/util/include/linux/const.h
7e3f36411342a54f1981fa97b43550b8406a3d69 perf tools: Remove tools/perf/util/include/asm/byteorder.h
14f0652b4fbebd0b05da36a06b17ac6d4d87a8f8 perf tools: Add missing linux/compiler.h include to perf-sys.h

Available on my repo/branch:

git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git perf/core

I don't know exactly how linux-next works, would it be possible to merge in this branch
till it gets into tip/perf/core?

- Arnaldo

Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree

[Stephen Rothwell]

Hi Arnaldo,

On Mon, 18 Jul 2016 21:39:06 -0300 Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
>
> Em Tue, Jul 19, 2016 at 10:26:29AM +1000, Stephen Rothwell escreveu:
>  
> > If you have a single patch (or few) relative to yesterday's tip tree,
> > please send it to me as well and I will apply it as a fix patch if Ingo
> > doesn't get to pulling in time.  
> 
> [acme@jouet linux]$ git log --pretty=oneline  9fcfcdf3c7b613c0d9536f57587456411b8a4e33..ae3c14a028ed10552803b68276b6833295ba18cf 
> ae3c14a028ed10552803b68276b6833295ba18cf tools: Copy linux/{hash,poison}.h and check for drift
> 3aa0042769313b720142c0ef8514dac389e14ebe perf tools: Remove include/linux/list.h from perf's MANIFEST
> de1e17b1d0c81be472039798698b517c8a68b516 tools: Copy the bitops files accessed from the kernel and check for drift
> ad430729ae00dd63f7dcadbeb638e589bc03b5a3 Remove: kernel unistd*h files from perf's MANIFEST, not used
> e0643c4e9fdb2e77ab83ca596460e2c9c15728aa perf tools: Remove tools/perf/util/include/linux/const.h
> 7e3f36411342a54f1981fa97b43550b8406a3d69 perf tools: Remove tools/perf/util/include/asm/byteorder.h
> 14f0652b4fbebd0b05da36a06b17ac6d4d87a8f8 perf tools: Add missing linux/compiler.h include to perf-sys.h
> 
> Available on my repo/branch:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git perf/core
> 
> I don't know exactly how linux-next works, would it be possible to merge in this branch
> till it gets into tip/perf/core?

OK, I added this to linux-next today (as a temporary measure), but it
fails the same way.  To be clear, I merged the above branch (without
the rest of the tip tree) and it fails the same way. :-(

It produces these errors (from the x86_64 allmodconfig build):

In file included from /home/sfr/next/next/tools/arch/x86/include/uapi/asm/bitsperlong.h:10:0,
                 from /usr/include/asm-generic/int-ll64.h:11,
                 from /usr/include/powerpc64le-linux-gnu/asm/types.h:27,
                 from /home/sfr/next/next/tools/include/linux/types.h:9,
                 from /home/sfr/next/next/tools/include/linux/list.h:4,
                 from elf.h:23,
                 from elf.c:30:
/home/sfr/next/next/tools/include/asm-generic/bitsperlong.h:13:2: error: #error Inconsistent word size. Check asm/bitsperlong.h
 #error Inconsistent word size. Check asm/bitsperlong.h
  ^

(and more similar).

I have applied my patch from yesterday ("tools: Simplify
__BITS_PER_LONG define"), and will continue on.

-- 
Cheers,
Stephen Rothwell

Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree

[Arnaldo Carvalho de Melo]

Em Tue, Jul 19, 2016 at 01:26:08PM +1000, Stephen Rothwell escreveu:
> Hi Arnaldo,
> 
> On Mon, 18 Jul 2016 21:39:06 -0300 Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
> >
> > Em Tue, Jul 19, 2016 at 10:26:29AM +1000, Stephen Rothwell escreveu:
> >  
> > > If you have a single patch (or few) relative to yesterday's tip tree,
> > > please send it to me as well and I will apply it as a fix patch if Ingo
> > > doesn't get to pulling in time.  
> > 
> > [acme@jouet linux]$ git log --pretty=oneline  9fcfcdf3c7b613c0d9536f57587456411b8a4e33..ae3c14a028ed10552803b68276b6833295ba18cf 
> > ae3c14a028ed10552803b68276b6833295ba18cf tools: Copy linux/{hash,poison}.h and check for drift
> > 3aa0042769313b720142c0ef8514dac389e14ebe perf tools: Remove include/linux/list.h from perf's MANIFEST
> > de1e17b1d0c81be472039798698b517c8a68b516 tools: Copy the bitops files accessed from the kernel and check for drift
> > ad430729ae00dd63f7dcadbeb638e589bc03b5a3 Remove: kernel unistd*h files from perf's MANIFEST, not used
> > e0643c4e9fdb2e77ab83ca596460e2c9c15728aa perf tools: Remove tools/perf/util/include/linux/const.h
> > 7e3f36411342a54f1981fa97b43550b8406a3d69 perf tools: Remove tools/perf/util/include/asm/byteorder.h
> > 14f0652b4fbebd0b05da36a06b17ac6d4d87a8f8 perf tools: Add missing linux/compiler.h include to perf-sys.h
> > 
> > Available on my repo/branch:
> > 
> > git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git perf/core
> > 
> > I don't know exactly how linux-next works, would it be possible to merge in this branch
> > till it gets into tip/perf/core?
> 
> OK, I added this to linux-next today (as a temporary measure), but it
> fails the same way.  To be clear, I merged the above branch (without
> the rest of the tip tree) and it fails the same way. :-(
> 
> It produces these errors (from the x86_64 allmodconfig build):
> 
> In file included from /home/sfr/next/next/tools/arch/x86/include/uapi/asm/bitsperlong.h:10:0,
>                  from /usr/include/asm-generic/int-ll64.h:11,
>                  from /usr/include/powerpc64le-linux-gnu/asm/types.h:27,
>                  from /home/sfr/next/next/tools/include/linux/types.h:9,
>                  from /home/sfr/next/next/tools/include/linux/list.h:4,
>                  from elf.h:23,
>                  from elf.c:30:
> /home/sfr/next/next/tools/include/asm-generic/bitsperlong.h:13:2: error: #error Inconsistent word size. Check asm/bitsperlong.h
>  #error Inconsistent word size. Check asm/bitsperlong.h
>   ^
> 
> (and more similar).
> 
> I have applied my patch from yesterday ("tools: Simplify
> __BITS_PER_LONG define"), and will continue on.

Ok, I'm trying the other way around, i.e. building a ppc64 kernel on a
x86_64 machine, that is one setup I have access to easily.

- Arnaldo

Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree

[Arnaldo Carvalho de Melo]

Em Tue, Jul 19, 2016 at 09:54:43AM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Tue, Jul 19, 2016 at 01:26:08PM +1000, Stephen Rothwell escreveu:
> > On Mon, 18 Jul 2016 21:39:06 -0300 Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
> > > Em Tue, Jul 19, 2016 at 10:26:29AM +1000, Stephen Rothwell escreveu:
> > > > If you have a single patch (or few) relative to yesterday's tip tree,
> > > > please send it to me as well and I will apply it as a fix patch if Ingo
> > > > doesn't get to pulling in time.  

> > > [acme@jouet linux]$ git log --pretty=oneline  9fcfcdf3c7b613c0d9536f57587456411b8a4e33..ae3c14a028ed10552803b68276b6833295ba18cf 
> > > ae3c14a028ed10552803b68276b6833295ba18cf tools: Copy linux/{hash,poison}.h and check for drift
> > > 3aa0042769313b720142c0ef8514dac389e14ebe perf tools: Remove include/linux/list.h from perf's MANIFEST
> > > de1e17b1d0c81be472039798698b517c8a68b516 tools: Copy the bitops files accessed from the kernel and check for drift
> > > ad430729ae00dd63f7dcadbeb638e589bc03b5a3 Remove: kernel unistd*h files from perf's MANIFEST, not used
> > > e0643c4e9fdb2e77ab83ca596460e2c9c15728aa perf tools: Remove tools/perf/util/include/linux/const.h
> > > 7e3f36411342a54f1981fa97b43550b8406a3d69 perf tools: Remove tools/perf/util/include/asm/byteorder.h
> > > 14f0652b4fbebd0b05da36a06b17ac6d4d87a8f8 perf tools: Add missing linux/compiler.h include to perf-sys.h

> > > Available on my repo/branch:

> > > git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git perf/core
> > > 
> > > I don't know exactly how linux-next works, would it be possible to merge in this branch
> > > till it gets into tip/perf/core?
> > 
> > OK, I added this to linux-next today (as a temporary measure), but it
> > fails the same way.  To be clear, I merged the above branch (without
> > the rest of the tip tree) and it fails the same way. :-(
> > 
> > It produces these errors (from the x86_64 allmodconfig build):
> > 
> > In fVile included from /home/sfr/next/next/tools/arch/x86/include/uapi/asm/bitsperlong.h:10:0,
> >                  from /usr/include/asm-generic/int-ll64.h:11,
> >                  from /usr/include/powerpc64le-linux-gnu/asm/types.h:27,
> >                  from /home/sfr/next/next/tools/include/linux/types.h:9,
> >                  from /home/sfr/next/next/tools/include/linux/list.h:4,
> >                  from elf.h:23,
> >                  from elf.c:30:
> > /home/sfr/next/next/tools/include/asm-generic/bitsperlong.h:13:2: error: #error Inconsistent word size. Check asm/bitsperlong.h
> >  #error Inconsistent word size. Check asm/bitsperlong.h
> >   ^
> > 
> > (and more similar).
> > 
> > I have applied my patch from yesterday ("tools: Simplify
> > __BITS_PER_LONG define"), and will continue on.
> 
> Ok, I'm trying the other way around, i.e. building a ppc64 kernel on a
> x86_64 machine, that is one setup I have access to easily.

No such luck, everything works as expected, objtool doesn't even get
compiled, likely it doesn't support powerpc binaries so it isn't built:

$ make -j4 O=../build/ppc-v4.7.0-rc5+/ ARCH=powerpc CROSS_COMPILE=ppc64-linux-gnu- allmodconfig
$ make -j4 O=../build/ppc-v4.7.0-rc5+/ ARCH=powerpc CROSS_COMPILE=ppc64-linux-gnu-
<SNIP>
  IHEX2FW firmware/keyspan_pda/xircom_pgs.fw
  IHEX    firmware/cpia2/stv0672_vp4.bin
  IHEX    firmware/yam/1200.bin
  IHEX    firmware/yam/9600.bin
make[1]: Leaving directory '/home/acme/git/build/ppc-v4.7.0-rc5+'
[acme@jouet linux]$
[acme@jouet linux]$ file ../build/ppc-v4.7.0-rc5+/vmlinux
../build/ppc-v4.7.0-rc5+/vmlinux: ELF 64-bit MSB executable, 64-bit PowerPC or cisco 7500, version 1 (SYSV), statically linked, BuildID[sha1]=eeb5449106c3dd7f803a611449f2deaf792d5312, not stripped

cross compiling to x86-32 bits from x86-64 also works :-\

/me scratches head

Probably it got the local definition of bitsperlong.h, i.e. the size on the host build
and then comparing it against the one for the target host...

Anyway, can you try the patch below to see what value is landing on __BITS_PER_LONG?

diff --git a/tools/include/asm-generic/bitsperlong.h b/tools/include/asm-generic/bitsperlong.h
index 45eca517efb3..c8f971e0d6a1 100644
--- a/tools/include/asm-generic/bitsperlong.h
+++ b/tools/include/asm-generic/bitsperlong.h
@@ -10,6 +10,9 @@
 #endif
 
 #if BITS_PER_LONG != __BITS_PER_LONG
+#include <linux/stringify.h>
+#pragma message "BITS_PER_LONG=" __stringify(BITS_PER_LONG)
+#pragma message "__BITS_PER_LONG=" __stringify(__BITS_PER_LONG)
 #error Inconsistent word size. Check asm/bitsperlong.h
 #endif
 

Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree

[Stephen Rothwell]

Hi Arnaldo,

On Tue, 19 Jul 2016 14:45:51 -0300 Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
>
> No such luck, everything works as expected, objtool doesn't even get
> compiled, likely it doesn't support powerpc binaries so it isn't built:

right.

> Probably it got the local definition of bitsperlong.h, i.e. the size on the host build
> and then comparing it against the one for the target host...
> 
> Anyway, can you try the patch below to see what value is landing on __BITS_PER_LONG?
> 
> diff --git a/tools/include/asm-generic/bitsperlong.h b/tools/include/asm-generic/bitsperlong.h
> index 45eca517efb3..c8f971e0d6a1 100644
> --- a/tools/include/asm-generic/bitsperlong.h
> +++ b/tools/include/asm-generic/bitsperlong.h
> @@ -10,6 +10,9 @@
>  #endif
>  
>  #if BITS_PER_LONG != __BITS_PER_LONG
> +#include <linux/stringify.h>
> +#pragma message "BITS_PER_LONG=" __stringify(BITS_PER_LONG)
> +#pragma message "__BITS_PER_LONG=" __stringify(__BITS_PER_LONG)
>  #error Inconsistent word size. Check asm/bitsperlong.h
>  #endif

I added those three lines to the file (just in yesterday's linux-next
was easiest) and got this:

/home/sfr/next/next/tools/include/asm-generic/bitsperlong.h:14:9: note: #pragma message: BITS_PER_LONG=(8 * 8)
 #pragma message "BITS_PER_LONG=" __stringify(BITS_PER_LONG)
         ^
/home/sfr/next/next/tools/include/asm-generic/bitsperlong.h:15:9: note: #pragma message: __BITS_PER_LONG=32
 #pragma message "__BITS_PER_LONG=" __stringify(__BITS_PER_LONG)
         ^

(a few times, of course)
-- 
Cheers,
Stephen Rothwell

Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree

[Stephen Rothwell]

Hi Arnaldo,

On Wed, 20 Jul 2016 09:21:57 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Tue, 19 Jul 2016 14:45:51 -0300 Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
> >
> > No such luck, everything works as expected, objtool doesn't even get
> > compiled, likely it doesn't support powerpc binaries so it isn't built:  
> 
> right.
> 
> > Probably it got the local definition of bitsperlong.h, i.e. the size on the host build
> > and then comparing it against the one for the target host...
> > 
> > Anyway, can you try the patch below to see what value is landing on __BITS_PER_LONG?
> > 
> > diff --git a/tools/include/asm-generic/bitsperlong.h b/tools/include/asm-generic/bitsperlong.h
> > index 45eca517efb3..c8f971e0d6a1 100644
> > --- a/tools/include/asm-generic/bitsperlong.h
> > +++ b/tools/include/asm-generic/bitsperlong.h
> > @@ -10,6 +10,9 @@
> >  #endif
> >  
> >  #if BITS_PER_LONG != __BITS_PER_LONG
> > +#include <linux/stringify.h>
> > +#pragma message "BITS_PER_LONG=" __stringify(BITS_PER_LONG)
> > +#pragma message "__BITS_PER_LONG=" __stringify(__BITS_PER_LONG)
> >  #error Inconsistent word size. Check asm/bitsperlong.h
> >  #endif  
> 
> I added those three lines to the file (just in yesterday's linux-next
> was easiest) and got this:
> 
> /home/sfr/next/next/tools/include/asm-generic/bitsperlong.h:14:9: note: #pragma message: BITS_PER_LONG=(8 * 8)
>  #pragma message "BITS_PER_LONG=" __stringify(BITS_PER_LONG)
>          ^
> /home/sfr/next/next/tools/include/asm-generic/bitsperlong.h:15:9: note: #pragma message: __BITS_PER_LONG=32
>  #pragma message "__BITS_PER_LONG=" __stringify(__BITS_PER_LONG)
>          ^
> 
> (a few times, of course)

So I applied this:

diff --git a/tools/arch/x86/include/uapi/asm/bitsperlong.h b/tools/arch/x86/include/uapi/asm/bitsperlong.h
index 6e23c543cd80..fd299f5468cb 100644
--- a/tools/arch/x86/include/uapi/asm/bitsperlong.h
+++ b/tools/arch/x86/include/uapi/asm/bitsperlong.h
@@ -4,6 +4,12 @@
 #if defined(__x86_64__) && !defined(__ILP32__)
 # define __BITS_PER_LONG 64
 #else
+#ifndef __x86_64__
+#pragma message "__x86_64__ is not defined"
+#endif
+#ifdef __ILP32__
+#pragma message "__ILP32__ is defined"
+#endif
 # define __BITS_PER_LONG 32
 #endif

and got this:

/home/sfr/next/next/tools/arch/x86/include/uapi/asm/bitsperlong.h:8:9: note: #pragma message: __x86_64__ is not defined
 #pragma message "__x86_64__ is not defined"

-- 
Cheers,
Stephen Rothwell

Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree

[Arnaldo Carvalho de Melo]

Em Wed, Jul 20, 2016 at 09:53:33AM +1000, Stephen Rothwell escreveu:
> On Wed, 20 Jul 2016 09:21:57 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> > On Tue, 19 Jul 2016 14:45:51 -0300 Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
> > >  #if BITS_PER_LONG != __BITS_PER_LONG
> > > +#include <linux/stringify.h>
> > > +#pragma message "BITS_PER_LONG=" __stringify(BITS_PER_LONG)
> > > +#pragma message "__BITS_PER_LONG=" __stringify(__BITS_PER_LONG)
> > >  #error Inconsistent word size. Check asm/bitsperlong.h
> > >  #endif  

> > I added those three lines to the file (just in yesterday's linux-next
> > was easiest) and got this:

> > /home/sfr/next/next/tools/include/asm-generic/bitsperlong.h:14:9: note: #pragma message: BITS_PER_LONG=(8 * 8)
> >  #pragma message "BITS_PER_LONG=" __stringify(BITS_PER_LONG)

> > /home/sfr/next/next/tools/include/asm-generic/bitsperlong.h:15:9: note: #pragma message: __BITS_PER_LONG=32
> >  #pragma message "__BITS_PER_LONG=" __stringify(__BITS_PER_LONG)

> > (a few times, of course)
 
> So I applied this:
 
> +++ b/tools/arch/x86/include/uapi/asm/bitsperlong.h
> @@ -4,6 +4,12 @@
>  #if defined(__x86_64__) && !defined(__ILP32__)
>  # define __BITS_PER_LONG 64
>  #else
> +#ifndef __x86_64__
> +#pragma message "__x86_64__ is not defined"
> +#endif
> +#ifdef __ILP32__
> +#pragma message "__ILP32__ is defined"
> +#endif
>  # define __BITS_PER_LONG 32
>  #endif
 
> and got this:
 
> /home/sfr/next/next/tools/arch/x86/include/uapi/asm/bitsperlong.h:8:9: note: #pragma message: __x86_64__ is not defined
>  #pragma message "__x86_64__ is not defined"

Humm, it seems that the compiler used is not the cross one, but the
native, check if, say, __powerpc__ is defined.

- Arnaldo

Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree

[Andy Lutomirski]

On Tue, Jul 19, 2016 at 7:52 PM, Arnaldo Carvalho de Melo
<acme@kernel.org> wrote:
> Em Wed, Jul 20, 2016 at 09:53:33AM +1000, Stephen Rothwell escreveu:
>> On Wed, 20 Jul 2016 09:21:57 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>> > On Tue, 19 Jul 2016 14:45:51 -0300 Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
>> > >  #if BITS_PER_LONG != __BITS_PER_LONG
>> > > +#include <linux/stringify.h>
>> > > +#pragma message "BITS_PER_LONG=" __stringify(BITS_PER_LONG)
>> > > +#pragma message "__BITS_PER_LONG=" __stringify(__BITS_PER_LONG)
>> > >  #error Inconsistent word size. Check asm/bitsperlong.h
>> > >  #endif
>
>> > I added those three lines to the file (just in yesterday's linux-next
>> > was easiest) and got this:
>
>> > /home/sfr/next/next/tools/include/asm-generic/bitsperlong.h:14:9: note: #pragma message: BITS_PER_LONG=(8 * 8)
>> >  #pragma message "BITS_PER_LONG=" __stringify(BITS_PER_LONG)
>
>> > /home/sfr/next/next/tools/include/asm-generic/bitsperlong.h:15:9: note: #pragma message: __BITS_PER_LONG=32
>> >  #pragma message "__BITS_PER_LONG=" __stringify(__BITS_PER_LONG)
>
>> > (a few times, of course)
>
>> So I applied this:
>
>> +++ b/tools/arch/x86/include/uapi/asm/bitsperlong.h
>> @@ -4,6 +4,12 @@
>>  #if defined(__x86_64__) && !defined(__ILP32__)
>>  # define __BITS_PER_LONG 64
>>  #else
>> +#ifndef __x86_64__
>> +#pragma message "__x86_64__ is not defined"
>> +#endif
>> +#ifdef __ILP32__
>> +#pragma message "__ILP32__ is defined"
>> +#endif
>>  # define __BITS_PER_LONG 32
>>  #endif
>
>> and got this:
>
>> /home/sfr/next/next/tools/arch/x86/include/uapi/asm/bitsperlong.h:8:9: note: #pragma message: __x86_64__ is not defined
>>  #pragma message "__x86_64__ is not defined"
>
> Humm, it seems that the compiler used is not the cross one, but the
> native, check if, say, __powerpc__ is defined.
>

This is still vdso2c, right?  It's a hostprog.

This stuff is utterly screwed up.  We're building a hostprog for an
x86_64 kernel cross-compiled from powerpc.  We should presumably be
pullng in powerpc's uapi headers for hostprogs because it's a *host*
prog.

--Andy

> - Arnaldo



-- 
Andy Lutomirski
AMA Capital Management, LLC

Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree

[Arnaldo Carvalho de Melo]

Em Tue, Jul 19, 2016 at 07:57:24PM -0700, Andy Lutomirski escreveu:
> On Tue, Jul 19, 2016 at 7:52 PM, Arnaldo Carvalho de Melo
> <acme@kernel.org> wrote:
> > Em Wed, Jul 20, 2016 at 09:53:33AM +1000, Stephen Rothwell escreveu:
> >> On Wed, 20 Jul 2016 09:21:57 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >> > On Tue, 19 Jul 2016 14:45:51 -0300 Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
> >> > >  #if BITS_PER_LONG != __BITS_PER_LONG
> >> > > +#include <linux/stringify.h>
> >> > > +#pragma message "BITS_PER_LONG=" __stringify(BITS_PER_LONG)
> >> > > +#pragma message "__BITS_PER_LONG=" __stringify(__BITS_PER_LONG)
> >> > >  #error Inconsistent word size. Check asm/bitsperlong.h
> >> > >  #endif
> >
> >> > I added those three lines to the file (just in yesterday's linux-next
> >> > was easiest) and got this:
> >
> >> > /home/sfr/next/next/tools/include/asm-generic/bitsperlong.h:14:9: note: #pragma message: BITS_PER_LONG=(8 * 8)
> >> >  #pragma message "BITS_PER_LONG=" __stringify(BITS_PER_LONG)
> >
> >> > /home/sfr/next/next/tools/include/asm-generic/bitsperlong.h:15:9: note: #pragma message: __BITS_PER_LONG=32
> >> >  #pragma message "__BITS_PER_LONG=" __stringify(__BITS_PER_LONG)
> >
> >> > (a few times, of course)
> >
> >> So I applied this:
> >
> >> +++ b/tools/arch/x86/include/uapi/asm/bitsperlong.h
> >> @@ -4,6 +4,12 @@
> >>  #if defined(__x86_64__) && !defined(__ILP32__)
> >>  # define __BITS_PER_LONG 64
> >>  #else
> >> +#ifndef __x86_64__
> >> +#pragma message "__x86_64__ is not defined"
> >> +#endif
> >> +#ifdef __ILP32__
> >> +#pragma message "__ILP32__ is defined"
> >> +#endif
> >>  # define __BITS_PER_LONG 32
> >>  #endif
> >
> >> and got this:
> >
> >> /home/sfr/next/next/tools/arch/x86/include/uapi/asm/bitsperlong.h:8:9: note: #pragma message: __x86_64__ is not defined
> >>  #pragma message "__x86_64__ is not defined"
> >
> > Humm, it seems that the compiler used is not the cross one, but the
> > native, check if, say, __powerpc__ is defined.
> >
> 
> This is still vdso2c, right?  It's a hostprog.
> 
> This stuff is utterly screwed up.  We're building a hostprog for an
> x86_64 kernel cross-compiled from powerpc.  We should presumably be
> pullng in powerpc's uapi headers for hostprogs because it's a *host*
> prog.

Unsure, I thought that what was breaking was objtool (tools/objtool),
Stephen?

- Arnaldo

Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree

[Stephen Rothwell]

Hi Arnaldo,

On Wed, 20 Jul 2016 00:09:24 -0300 Arnaldo Carvalho de Melo <acme@redhat.com> wrote:
>
> Em Tue, Jul 19, 2016 at 07:57:24PM -0700, Andy Lutomirski escreveu:
> > On Tue, Jul 19, 2016 at 7:52 PM, Arnaldo Carvalho de Melo
> > <acme@kernel.org> wrote:  
> > > Em Wed, Jul 20, 2016 at 09:53:33AM +1000, Stephen Rothwell escreveu:  
> > >> On Wed, 20 Jul 2016 09:21:57 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:  
> > >> > On Tue, 19 Jul 2016 14:45:51 -0300 Arnaldo Carvalho de Melo <acme@kernel.org> wrote:  
> > >> > >  #if BITS_PER_LONG != __BITS_PER_LONG
> > >> > > +#include <linux/stringify.h>
> > >> > > +#pragma message "BITS_PER_LONG=" __stringify(BITS_PER_LONG)
> > >> > > +#pragma message "__BITS_PER_LONG=" __stringify(__BITS_PER_LONG)
> > >> > >  #error Inconsistent word size. Check asm/bitsperlong.h
> > >> > >  #endif  
> > >  
> > >> > I added those three lines to the file (just in yesterday's linux-next
> > >> > was easiest) and got this:  
> > >  
> > >> > /home/sfr/next/next/tools/include/asm-generic/bitsperlong.h:14:9: note: #pragma message: BITS_PER_LONG=(8 * 8)
> > >> >  #pragma message "BITS_PER_LONG=" __stringify(BITS_PER_LONG)  
> > >  
> > >> > /home/sfr/next/next/tools/include/asm-generic/bitsperlong.h:15:9: note: #pragma message: __BITS_PER_LONG=32
> > >> >  #pragma message "__BITS_PER_LONG=" __stringify(__BITS_PER_LONG)  
> > >  
> > >> > (a few times, of course)  
> > >  
> > >> So I applied this:  
> > >  
> > >> +++ b/tools/arch/x86/include/uapi/asm/bitsperlong.h
> > >> @@ -4,6 +4,12 @@
> > >>  #if defined(__x86_64__) && !defined(__ILP32__)
> > >>  # define __BITS_PER_LONG 64
> > >>  #else
> > >> +#ifndef __x86_64__
> > >> +#pragma message "__x86_64__ is not defined"
> > >> +#endif
> > >> +#ifdef __ILP32__
> > >> +#pragma message "__ILP32__ is defined"
> > >> +#endif
> > >>  # define __BITS_PER_LONG 32
> > >>  #endif  
> > >  
> > >> and got this:  
> > >  
> > >> /home/sfr/next/next/tools/arch/x86/include/uapi/asm/bitsperlong.h:8:9: note: #pragma message: __x86_64__ is not defined
> > >>  #pragma message "__x86_64__ is not defined"  
> > >
> > > Humm, it seems that the compiler used is not the cross one, but the
> > > native, check if, say, __powerpc__ is defined.
> > >  
> > 
> > This is still vdso2c, right?  It's a hostprog.
> > 
> > This stuff is utterly screwed up.  We're building a hostprog for an
> > x86_64 kernel cross-compiled from powerpc.  We should presumably be
> > pullng in powerpc's uapi headers for hostprogs because it's a *host*
> > prog.  
> 
> Unsure, I thought that what was breaking was objtool (tools/objtool),
> Stephen?

Yes, it is objtool, but that is also a host program and so should be
using the host architectures includes, right?  Thanks for pointing that out
Andy,

-- 
Cheers,
Stephen Rothwell

Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree

[Stephen Rothwell]

Hi Arnaldo,

On Tue, 19 Jul 2016 23:52:02 -0300 Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
>
> Humm, it seems that the compiler used is not the cross one, but the
> native, check if, say, __powerpc__ is defined.

Yes, __powerpc__ is defined (unsuprisingly).

-- 
Cheers,
Stephen Rothwell

Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree

[Arnaldo Carvalho de Melo]

Em Thu, Jul 21, 2016 at 09:29:50AM +1000, Stephen Rothwell escreveu:
> Hi Arnaldo,
> 
> On Tue, 19 Jul 2016 23:52:02 -0300 Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
> >
> > Humm, it seems that the compiler used is not the cross one, but the
> > native, check if, say, __powerpc__ is defined.
> 
> Yes, __powerpc__ is defined (unsuprisingly).

Maybe this one?

diff --git a/tools/objtool/Makefile b/tools/objtool/Makefile
index 1f75b0a046cc..3500fcf7bd47 100644
--- a/tools/objtool/Makefile
+++ b/tools/objtool/Makefile
@@ -1,10 +1,14 @@
 include ../scripts/Makefile.include
 
+HOSTARCH=$(shell uname -m | sed -e s/i.86/x86/ -e s/x86_64/x86/ \
+                                -e s/sun4u/sparc64/ \
+                                -e s/arm.*/arm/ -e s/sa110/arm/ \
+                                -e s/s390x/s390/ -e s/parisc64/parisc/ \
+                                -e s/ppc.*/powerpc/ -e s/mips.*/mips/ \
+                                -e s/sh[234].*/sh/ -e s/aarch64.*/arm64/ )
+
 ifndef ($(ARCH))
-ARCH ?= $(shell uname -m)
-ifeq ($(ARCH),x86_64)
-ARCH := x86
-endif
+ARCH ?= $(HOSTARCH)
 endif
 
 # always use the host compiler
@@ -26,7 +30,7 @@ OBJTOOL_IN := $(OBJTOOL)-in.o
 
 all: $(OBJTOOL)
 
-INCLUDES := -I$(srctree)/tools/include -I$(srctree)/tools/arch/$(ARCH)/include/uapi
+INCLUDES := -I$(srctree)/tools/include -I$(srctree)/tools/arch/$(HOSTARCH)/include/uapi
 CFLAGS   += -Wall -Werror $(EXTRA_WARNINGS) -fomit-frame-pointer -O2 -g $(INCLUDES)
 LDFLAGS  += -lelf $(LIBSUBCMD)
 

Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree

[Stephen Rothwell]

Hi Arnaldo,

On Thu, 21 Jul 2016 10:12:48 -0300 Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
>
> Em Thu, Jul 21, 2016 at 09:29:50AM +1000, Stephen Rothwell escreveu:
> > Hi Arnaldo,
> > 
> > On Tue, 19 Jul 2016 23:52:02 -0300 Arnaldo Carvalho de Melo <acme@kernel.org> wrote:  
> > >
> > > Humm, it seems that the compiler used is not the cross one, but the
> > > native, check if, say, __powerpc__ is defined.  
> > 
> > Yes, __powerpc__ is defined (unsuprisingly).  
> 
> Maybe this one?
> 
> diff --git a/tools/objtool/Makefile b/tools/objtool/Makefile
> index 1f75b0a046cc..3500fcf7bd47 100644
> --- a/tools/objtool/Makefile
> +++ b/tools/objtool/Makefile
> @@ -1,10 +1,14 @@
>  include ../scripts/Makefile.include
>  
> +HOSTARCH=$(shell uname -m | sed -e s/i.86/x86/ -e s/x86_64/x86/ \
> +                                -e s/sun4u/sparc64/ \
> +                                -e s/arm.*/arm/ -e s/sa110/arm/ \
> +                                -e s/s390x/s390/ -e s/parisc64/parisc/ \
> +                                -e s/ppc.*/powerpc/ -e s/mips.*/mips/ \
> +                                -e s/sh[234].*/sh/ -e s/aarch64.*/arm64/ )
> +
>  ifndef ($(ARCH))
> -ARCH ?= $(shell uname -m)
> -ifeq ($(ARCH),x86_64)
> -ARCH := x86
> -endif
> +ARCH ?= $(HOSTARCH)
>  endif
>  
>  # always use the host compiler
> @@ -26,7 +30,7 @@ OBJTOOL_IN := $(OBJTOOL)-in.o
>  
>  all: $(OBJTOOL)
>  
> -INCLUDES := -I$(srctree)/tools/include -I$(srctree)/tools/arch/$(ARCH)/include/uapi
> +INCLUDES := -I$(srctree)/tools/include -I$(srctree)/tools/arch/$(HOSTARCH)/include/uapi
>  CFLAGS   += -Wall -Werror $(EXTRA_WARNINGS) -fomit-frame-pointer -O2 -g $(INCLUDES)
>  LDFLAGS  += -lelf $(LIBSUBCMD)
>  

That gets me this errors from the x86_64 allmodconfig build:

tools/objtool/objtool-in.o: In function `decode_instructions':
tools/objtool/builtin-check.c:276: undefined reference to `arch_decode_instruction'

It just looks like objtool was not written with cross compilation in
mind?  It seems to build and run OK when you remove the test that
checks that BITS_PER_LONG and __BITS_PER_LONG are the same, but I have
no idea if it getting the desired results.
-- 
Cheers,
Stephen Rothwell

Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree

[Josh Poimboeuf]

On Fri, Jul 22, 2016 at 09:23:02AM +1000, Stephen Rothwell wrote:
> Hi Arnaldo,
> 
> On Thu, 21 Jul 2016 10:12:48 -0300 Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
> >
> > Em Thu, Jul 21, 2016 at 09:29:50AM +1000, Stephen Rothwell escreveu:
> > > Hi Arnaldo,
> > > 
> > > On Tue, 19 Jul 2016 23:52:02 -0300 Arnaldo Carvalho de Melo <acme@kernel.org> wrote:  
> > > >
> > > > Humm, it seems that the compiler used is not the cross one, but the
> > > > native, check if, say, __powerpc__ is defined.  
> > > 
> > > Yes, __powerpc__ is defined (unsuprisingly).  
> > 
> > Maybe this one?
> > 
> > diff --git a/tools/objtool/Makefile b/tools/objtool/Makefile
> > index 1f75b0a046cc..3500fcf7bd47 100644
> > --- a/tools/objtool/Makefile
> > +++ b/tools/objtool/Makefile
> > @@ -1,10 +1,14 @@
> >  include ../scripts/Makefile.include
> >  
> > +HOSTARCH=$(shell uname -m | sed -e s/i.86/x86/ -e s/x86_64/x86/ \
> > +                                -e s/sun4u/sparc64/ \
> > +                                -e s/arm.*/arm/ -e s/sa110/arm/ \
> > +                                -e s/s390x/s390/ -e s/parisc64/parisc/ \
> > +                                -e s/ppc.*/powerpc/ -e s/mips.*/mips/ \
> > +                                -e s/sh[234].*/sh/ -e s/aarch64.*/arm64/ )
> > +
> >  ifndef ($(ARCH))
> > -ARCH ?= $(shell uname -m)
> > -ifeq ($(ARCH),x86_64)
> > -ARCH := x86
> > -endif
> > +ARCH ?= $(HOSTARCH)
> >  endif
> >  
> >  # always use the host compiler
> > @@ -26,7 +30,7 @@ OBJTOOL_IN := $(OBJTOOL)-in.o
> >  
> >  all: $(OBJTOOL)
> >  
> > -INCLUDES := -I$(srctree)/tools/include -I$(srctree)/tools/arch/$(ARCH)/include/uapi
> > +INCLUDES := -I$(srctree)/tools/include -I$(srctree)/tools/arch/$(HOSTARCH)/include/uapi
> >  CFLAGS   += -Wall -Werror $(EXTRA_WARNINGS) -fomit-frame-pointer -O2 -g $(INCLUDES)
> >  LDFLAGS  += -lelf $(LIBSUBCMD)
> >  
> 
> That gets me this errors from the x86_64 allmodconfig build:
> 
> tools/objtool/objtool-in.o: In function `decode_instructions':
> tools/objtool/builtin-check.c:276: undefined reference to `arch_decode_instruction'
> 
> It just looks like objtool was not written with cross compilation in
> mind?

I don't know yet what the specific problem is, but objtool should work
fine in a cross-compiled environment.  It needs to be compiled with the
host (powerpc) compiler, but then it needs to disassemble target (x86)
files.  It worked fine before the bitsperlong.h files were merged.

I can try to take a deeper look at it tomorrow.

> It seems to build and run OK when you remove the test that
> checks that BITS_PER_LONG and __BITS_PER_LONG are the same, but I have
> no idea if it getting the desired results.

-- 
Josh

Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree

[Arnaldo Carvalho de Melo]

Em Thu, Jul 21, 2016 at 10:41:18PM -0500, Josh Poimboeuf escreveu:
> On Fri, Jul 22, 2016 at 09:23:02AM +1000, Stephen Rothwell wrote:
> > It just looks like objtool was not written with cross compilation in
> > mind?
 
> I don't know yet what the specific problem is, but objtool should work
> fine in a cross-compiled environment.  It needs to be compiled with the
> host (powerpc) compiler, but then it needs to disassemble target (x86)
> files.  It worked fine before the bitsperlong.h files were merged.

So, trying to summarize from the various messages in this thread:

In Tue, Jul 19, 2016 at 01:26:08PM +1000, Stephen Rothwell wrote:

> It produces these errors (from the x86_64 allmodconfig build):
>
> In file included from
> /home/sfr/next/next/tools/arch/x86/include/uapi/asm/bitsperlong.h:10:0,
>                  from /usr/include/asm-generic/int-ll64.h:11,
>                  from /usr/include/powerpc64le-linux-gnu/asm/types.h:27,
>                  from /home/sfr/next/next/tools/include/linux/types.h:9,
>                  from /home/sfr/next/next/tools/include/linux/list.h:4,
>                  from elf.h:23,
>                  from elf.c:30:
> /home/sfr/next/next/tools/include/asm-generic/bitsperlong.h:13:2:
> error: #error Inconsistent word size. Check asm/bitsperlong.h
>  #error Inconsistent word size. Check asm/bitsperlong.h
>   ^

So it starts at tools/arch/x86/include/uapi/asm/bitsperlong.h, and as
you mention, this should've instead be using the host headers, i.e.:

   tools/arch/powerpc/include/uapi/asm/bitsperlong.h

Which it will if it uses HOSTARCH in tools/objtool/Makefile when setting
up the header search path, I have two csets in my perf/core branch that
fixes this, and that are equivalent to the last patch Stephen tried:

  $ git log --oneline -2
  87f7dc54366a objtool: Use tools/scripts/Makefile.arch to get ARCH and HOSTARCH
  0eec6770ab60 tools build: Add HOSTARCH Makefile variable
  $ 

Ok, so now it uses the right file, see the whole sequence at the end of this
e-mail, but it boils down to:

-----------------------------------------------------------------------------
#if defined(__powerpc64__)
# define __BITS_PER_LONG 64
#else
# define __BITS_PER_LONG 32
#endif

#ifdef __SIZEOF_LONG__
#define BITS_PER_LONG (__CHAR_BIT__ * __SIZEOF_LONG__)
#else
#define BITS_PER_LONG __WORDSIZE
#endif

#if BITS_PER_LONG != __BITS_PER_LONG
#error Inconsistent word size. Check asm/bitsperlong.h
#endif
-----------------------------------------------------------------------------

Which I think has no problems, right? The last problem reported ty Stephen now is:

In Fri, 22 Jul 2016 09:23:02 +1000, Stephen Rothwell wrote:

> That gets me this errors from the x86_64 allmodconfig build:

> tools/objtool/objtool-in.o: In function `decode_instructions':
> tools/objtool/builtin-check.c:276: undefined reference to `arch_decode_instruction'

Should work, since ARCH should be x86 and then tools/objtool/Build will have
this:

objtool-y += arch/$(ARCH)/

Turned into:

objtool-y += arch/x86/

Which will build tools/objtool/arch/x86/decode.c, that will provide that
arch_decode_instruction() function :-\

I.e. with the two patches I mentioned, that are equivalent to the last patch I
sent to Stephen for testing, we would end up with HOSTARCH=powerpc and
ARCH=x86, no?

- Arnaldo

Full sequence:

[acme@jouet linux]$ cat tools/arch/powerpc/include/uapi/asm/bitsperlong.h 
#ifndef __ASM_POWERPC_BITSPERLONG_H
#define __ASM_POWERPC_BITSPERLONG_H

#if defined(__powerpc64__)
# define __BITS_PER_LONG 64
#else
# define __BITS_PER_LONG 32
#endif

#include <asm-generic/bitsperlong.h>

#endif /* __ASM_POWERPC_BITSPERLONG_H */
[acme@jouet linux]$

It, like the kernel, where these files come from, has:

[acme@jouet linux]$ cat tools/include/asm-generic/bitsperlong.h 
#ifndef __ASM_GENERIC_BITS_PER_LONG
#define __ASM_GENERIC_BITS_PER_LONG

#include <uapi/asm-generic/bitsperlong.h>

#ifdef __SIZEOF_LONG__
#define BITS_PER_LONG (__CHAR_BIT__ * __SIZEOF_LONG__)
#else
#define BITS_PER_LONG __WORDSIZE
#endif

#if BITS_PER_LONG != __BITS_PER_LONG
#error Inconsistent word size. Check asm/bitsperlong.h
#endif

#endif /* __ASM_GENERIC_BITS_PER_LONG */
[acme@jouet linux]$

And finally:

[acme@jouet linux]$ cat tools/include/uapi/asm-generic/bitsperlong.h 
#ifndef _UAPI__ASM_GENERIC_BITS_PER_LONG
#define _UAPI__ASM_GENERIC_BITS_PER_LONG

/*
 * There seems to be no way of detecting this automatically from user
 * space, so 64 bit architectures should override this in their
 * bitsperlong.h. In particular, an architecture that supports
 * both 32 and 64 bit user space must not rely on CONFIG_64BIT
 * to decide it, but rather check a compiler provided macro.
 */
#ifndef __BITS_PER_LONG
#define __BITS_PER_LONG 32
#endif

#endif /* _UAPI__ASM_GENERIC_BITS_PER_LONG */
[acme@jouet linux]$ 

Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree

[Josh Poimboeuf]

On Fri, Jul 22, 2016 at 11:37:39AM -0300, Arnaldo Carvalho de Melo wrote:
> Em Thu, Jul 21, 2016 at 10:41:18PM -0500, Josh Poimboeuf escreveu:
> > On Fri, Jul 22, 2016 at 09:23:02AM +1000, Stephen Rothwell wrote:
> > > It just looks like objtool was not written with cross compilation in
> > > mind?
>  
> > I don't know yet what the specific problem is, but objtool should work
> > fine in a cross-compiled environment.  It needs to be compiled with the
> > host (powerpc) compiler, but then it needs to disassemble target (x86)
> > files.  It worked fine before the bitsperlong.h files were merged.
> 
> So, trying to summarize from the various messages in this thread:
> 
> In Tue, Jul 19, 2016 at 01:26:08PM +1000, Stephen Rothwell wrote:
> 
> > It produces these errors (from the x86_64 allmodconfig build):
> >
> > In file included from
> > /home/sfr/next/next/tools/arch/x86/include/uapi/asm/bitsperlong.h:10:0,
> >                  from /usr/include/asm-generic/int-ll64.h:11,
> >                  from /usr/include/powerpc64le-linux-gnu/asm/types.h:27,
> >                  from /home/sfr/next/next/tools/include/linux/types.h:9,
> >                  from /home/sfr/next/next/tools/include/linux/list.h:4,
> >                  from elf.h:23,
> >                  from elf.c:30:
> > /home/sfr/next/next/tools/include/asm-generic/bitsperlong.h:13:2:
> > error: #error Inconsistent word size. Check asm/bitsperlong.h
> >  #error Inconsistent word size. Check asm/bitsperlong.h
> >   ^
> 
> So it starts at tools/arch/x86/include/uapi/asm/bitsperlong.h, and as
> you mention, this should've instead be using the host headers, i.e.:
> 
>    tools/arch/powerpc/include/uapi/asm/bitsperlong.h
> 
> Which it will if it uses HOSTARCH in tools/objtool/Makefile when setting
> up the header search path, I have two csets in my perf/core branch that
> fixes this, and that are equivalent to the last patch Stephen tried:
> 
>   $ git log --oneline -2
>   87f7dc54366a objtool: Use tools/scripts/Makefile.arch to get ARCH and HOSTARCH
>   0eec6770ab60 tools build: Add HOSTARCH Makefile variable
>   $ 
> 
> Ok, so now it uses the right file, see the whole sequence at the end of this
> e-mail, but it boils down to:
> 
> -----------------------------------------------------------------------------
> #if defined(__powerpc64__)
> # define __BITS_PER_LONG 64
> #else
> # define __BITS_PER_LONG 32
> #endif
> 
> #ifdef __SIZEOF_LONG__
> #define BITS_PER_LONG (__CHAR_BIT__ * __SIZEOF_LONG__)
> #else
> #define BITS_PER_LONG __WORDSIZE
> #endif
> 
> #if BITS_PER_LONG != __BITS_PER_LONG
> #error Inconsistent word size. Check asm/bitsperlong.h
> #endif
> -----------------------------------------------------------------------------
> 
> Which I think has no problems, right? The last problem reported ty Stephen now is:
> 
> In Fri, 22 Jul 2016 09:23:02 +1000, Stephen Rothwell wrote:
> 
> > That gets me this errors from the x86_64 allmodconfig build:
> 
> > tools/objtool/objtool-in.o: In function `decode_instructions':
> > tools/objtool/builtin-check.c:276: undefined reference to `arch_decode_instruction'
> 
> Should work, since ARCH should be x86 and then tools/objtool/Build will have
> this:
> 
> objtool-y += arch/$(ARCH)/
> 
> Turned into:
> 
> objtool-y += arch/x86/
> 
> Which will build tools/objtool/arch/x86/decode.c, that will provide that
> arch_decode_instruction() function :-\
> 
> I.e. with the two patches I mentioned, that are equivalent to the last patch I
> sent to Stephen for testing, we would end up with HOSTARCH=powerpc and
> ARCH=x86, no?

Thanks for spelling it out, that helped a lot.

I'm guessing Stephen is setting ARCH=x86_64 on the command-line rather
than ARCH=x86.  How about the following patch?  Stephen, can you confirm
this fixes it?  This is on top of Arnaldo's other two fixes here:

  https://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git perf/core

From: Josh Poimboeuf <jpoimboe@redhat.com>
Subject: [PATCH] tools build: fix objtool build with ARCH=x86_64

The objtool build fails in a cross-compiled environment on a non-x86
host with "ARCH=x86_64":

  tools/objtool/objtool-in.o: In function `decode_instructions':
  tools/objtool/builtin-check.c:276: undefined reference to `arch_decode_instruction'

We could override the ARCH environment variable and change it back to
x86, similar to what the objtool Makefile was doing before; but it's
tricky to override environment variables consistently.

Instead, take a similar approach used by the Linux top-level Makefile
and introduce a SRCARCH Makefile variable which evaluates to "x86" when
ARCH is either "x86_64" or "x86".

Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
---
 tools/objtool/Build         |  2 +-
 tools/objtool/Makefile      |  2 +-
 tools/scripts/Makefile.arch | 32 ++++++++++++++++++++++++++++++++
 3 files changed, 34 insertions(+), 2 deletions(-)

diff --git a/tools/objtool/Build b/tools/objtool/Build
index 2457916..d6cdece 100644
--- a/tools/objtool/Build
+++ b/tools/objtool/Build
@@ -1,4 +1,4 @@
-objtool-y += arch/$(ARCH)/
+objtool-y += arch/$(SRCARCH)/
 objtool-y += builtin-check.o
 objtool-y += elf.o
 objtool-y += special.o
diff --git a/tools/objtool/Makefile b/tools/objtool/Makefile
index c9ad80a..577f2d4 100644
--- a/tools/objtool/Makefile
+++ b/tools/objtool/Makefile
@@ -29,7 +29,7 @@ elfshdr := $(shell echo '\#include <libelf.h>' | $(CC) $(CFLAGS) -x c -E - | gre
 CFLAGS += $(if $(elfshdr),,-DLIBELF_USE_DEPRECATED)
 
 AWK = awk
-export srctree OUTPUT CFLAGS ARCH AWK
+export srctree OUTPUT CFLAGS SRCARCH AWK
 include $(srctree)/tools/build/Makefile.include
 
 $(OBJTOOL_IN): fixdep FORCE
diff --git a/tools/scripts/Makefile.arch b/tools/scripts/Makefile.arch
index 887321c..ad85b92 100644
--- a/tools/scripts/Makefile.arch
+++ b/tools/scripts/Makefile.arch
@@ -5,10 +5,42 @@ HOSTARCH := $(shell uname -m | sed -e s/i.86/x86/ -e s/x86_64/x86/ \
                                   -e s/ppc.*/powerpc/ -e s/mips.*/mips/ \
                                   -e s/sh[234].*/sh/ -e s/aarch64.*/arm64/ \
                                   -e s/tile.*/tile/ )
+
 ifndef ARCH
 ARCH := $(HOSTARCH)
 endif
 
+SRCARCH := $(ARCH)
+
+# Additional ARCH settings for x86
+ifeq ($(ARCH),i386)
+        SRCARCH := x86
+endif
+ifeq ($(ARCH),x86_64)
+        SRCARCH := x86
+endif
+
+# Additional ARCH settings for sparc
+ifeq ($(ARCH),sparc32)
+       SRCARCH := sparc
+endif
+ifeq ($(ARCH),sparc64)
+       SRCARCH := sparc
+endif
+
+# Additional ARCH settings for sh
+ifeq ($(ARCH),sh64)
+       SRCARCH := sh
+endif
+
+# Additional ARCH settings for tile
+ifeq ($(ARCH),tilepro)
+       SRCARCH := tile
+endif
+ifeq ($(ARCH),tilegx)
+       SRCARCH := tile
+endif
+
 LP64 := $(shell echo __LP64__ | ${CC} ${CFLAGS} -E -x c - | tail -n 1)
 ifeq ($(LP64), 1)
   IS_64_BIT := 1

Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree

[Arnaldo Carvalho de Melo]

Em Fri, Jul 22, 2016 at 02:19:20PM -0500, Josh Poimboeuf escreveu:
> On Fri, Jul 22, 2016 at 11:37:39AM -0300, Arnaldo Carvalho de Melo wrote:
> > Em Thu, Jul 21, 2016 at 10:41:18PM -0500, Josh Poimboeuf escreveu:
> > > On Fri, Jul 22, 2016 at 09:23:02AM +1000, Stephen Rothwell wrote:
> > > > It just looks like objtool was not written with cross compilation in
> > > > mind?
> >  
> > > I don't know yet what the specific problem is, but objtool should work
> > > fine in a cross-compiled environment.  It needs to be compiled with the
> > > host (powerpc) compiler, but then it needs to disassemble target (x86)
> > > files.  It worked fine before the bitsperlong.h files were merged.
> > 
> > So, trying to summarize from the various messages in this thread:
> > 
> > In Tue, Jul 19, 2016 at 01:26:08PM +1000, Stephen Rothwell wrote:
> > 
> > > It produces these errors (from the x86_64 allmodconfig build):
> > >
> > > In file included from
> > > /home/sfr/next/next/tools/arch/x86/include/uapi/asm/bitsperlong.h:10:0,
> > >                  from /usr/include/asm-generic/int-ll64.h:11,
> > >                  from /usr/include/powerpc64le-linux-gnu/asm/types.h:27,
> > >                  from /home/sfr/next/next/tools/include/linux/types.h:9,
> > >                  from /home/sfr/next/next/tools/include/linux/list.h:4,
> > >                  from elf.h:23,
> > >                  from elf.c:30:
> > > /home/sfr/next/next/tools/include/asm-generic/bitsperlong.h:13:2:
> > > error: #error Inconsistent word size. Check asm/bitsperlong.h
> > >  #error Inconsistent word size. Check asm/bitsperlong.h
> > >   ^
> > 
> > So it starts at tools/arch/x86/include/uapi/asm/bitsperlong.h, and as
> > you mention, this should've instead be using the host headers, i.e.:
> > 
> >    tools/arch/powerpc/include/uapi/asm/bitsperlong.h
> > 
> > Which it will if it uses HOSTARCH in tools/objtool/Makefile when setting
> > up the header search path, I have two csets in my perf/core branch that
> > fixes this, and that are equivalent to the last patch Stephen tried:
> > 
> >   $ git log --oneline -2
> >   87f7dc54366a objtool: Use tools/scripts/Makefile.arch to get ARCH and HOSTARCH
> >   0eec6770ab60 tools build: Add HOSTARCH Makefile variable
> >   $ 
> > 
> > Ok, so now it uses the right file, see the whole sequence at the end of this
> > e-mail, but it boils down to:
> > 
> > -----------------------------------------------------------------------------
> > #if defined(__powerpc64__)
> > # define __BITS_PER_LONG 64
> > #else
> > # define __BITS_PER_LONG 32
> > #endif
> > 
> > #ifdef __SIZEOF_LONG__
> > #define BITS_PER_LONG (__CHAR_BIT__ * __SIZEOF_LONG__)
> > #else
> > #define BITS_PER_LONG __WORDSIZE
> > #endif
> > 
> > #if BITS_PER_LONG != __BITS_PER_LONG
> > #error Inconsistent word size. Check asm/bitsperlong.h
> > #endif
> > -----------------------------------------------------------------------------
> > 
> > Which I think has no problems, right? The last problem reported ty Stephen now is:
> > 
> > In Fri, 22 Jul 2016 09:23:02 +1000, Stephen Rothwell wrote:
> > 
> > > That gets me this errors from the x86_64 allmodconfig build:
> > 
> > > tools/objtool/objtool-in.o: In function `decode_instructions':
> > > tools/objtool/builtin-check.c:276: undefined reference to `arch_decode_instruction'
> > 
> > Should work, since ARCH should be x86 and then tools/objtool/Build will have
> > this:
> > 
> > objtool-y += arch/$(ARCH)/
> > 
> > Turned into:
> > 
> > objtool-y += arch/x86/
> > 
> > Which will build tools/objtool/arch/x86/decode.c, that will provide that
> > arch_decode_instruction() function :-\
> > 
> > I.e. with the two patches I mentioned, that are equivalent to the last patch I
> > sent to Stephen for testing, we would end up with HOSTARCH=powerpc and
> > ARCH=x86, no?
> 
> Thanks for spelling it out, that helped a lot.

Glad you liked it, I had to do it for my own sanity :-)

And something that gave me mixed feelings was an e-mail from the kbuild
test bot that noticed my perf/core changes and said that the build was
broken for "make ARCH=x86_64", so I had to reinstate this part:

ifeq ($(ARCH),x86_64)
ARCH := x86
endif

Because, as you say, 'make ARCH=x86' works :-\ I think it will not be
needed with your patch, right? I'm checking your patch below right now,

- Arnaldo
 
> I'm guessing Stephen is setting ARCH=x86_64 on the command-line rather
> than ARCH=x86.  How about the following patch?  Stephen, can you confirm
> this fixes it?  This is on top of Arnaldo's other two fixes here:
> 
>   https://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git perf/core
> 
> From: Josh Poimboeuf <jpoimboe@redhat.com>
> Subject: [PATCH] tools build: fix objtool build with ARCH=x86_64
> 
> The objtool build fails in a cross-compiled environment on a non-x86
> host with "ARCH=x86_64":
> 
>   tools/objtool/objtool-in.o: In function `decode_instructions':
>   tools/objtool/builtin-check.c:276: undefined reference to `arch_decode_instruction'
> 
> We could override the ARCH environment variable and change it back to
> x86, similar to what the objtool Makefile was doing before; but it's
> tricky to override environment variables consistently.
> 
> Instead, take a similar approach used by the Linux top-level Makefile
> and introduce a SRCARCH Makefile variable which evaluates to "x86" when
> ARCH is either "x86_64" or "x86".
> 
> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
> Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
> ---
>  tools/objtool/Build         |  2 +-
>  tools/objtool/Makefile      |  2 +-
>  tools/scripts/Makefile.arch | 32 ++++++++++++++++++++++++++++++++
>  3 files changed, 34 insertions(+), 2 deletions(-)
> 
> diff --git a/tools/objtool/Build b/tools/objtool/Build
> index 2457916..d6cdece 100644
> --- a/tools/objtool/Build
> +++ b/tools/objtool/Build
> @@ -1,4 +1,4 @@
> -objtool-y += arch/$(ARCH)/
> +objtool-y += arch/$(SRCARCH)/
>  objtool-y += builtin-check.o
>  objtool-y += elf.o
>  objtool-y += special.o
> diff --git a/tools/objtool/Makefile b/tools/objtool/Makefile
> index c9ad80a..577f2d4 100644
> --- a/tools/objtool/Makefile
> +++ b/tools/objtool/Makefile
> @@ -29,7 +29,7 @@ elfshdr := $(shell echo '\#include <libelf.h>' | $(CC) $(CFLAGS) -x c -E - | gre
>  CFLAGS += $(if $(elfshdr),,-DLIBELF_USE_DEPRECATED)
>  
>  AWK = awk
> -export srctree OUTPUT CFLAGS ARCH AWK
> +export srctree OUTPUT CFLAGS SRCARCH AWK
>  include $(srctree)/tools/build/Makefile.include
>  
>  $(OBJTOOL_IN): fixdep FORCE
> diff --git a/tools/scripts/Makefile.arch b/tools/scripts/Makefile.arch
> index 887321c..ad85b92 100644
> --- a/tools/scripts/Makefile.arch
> +++ b/tools/scripts/Makefile.arch
> @@ -5,10 +5,42 @@ HOSTARCH := $(shell uname -m | sed -e s/i.86/x86/ -e s/x86_64/x86/ \
>                                    -e s/ppc.*/powerpc/ -e s/mips.*/mips/ \
>                                    -e s/sh[234].*/sh/ -e s/aarch64.*/arm64/ \
>                                    -e s/tile.*/tile/ )
> +
>  ifndef ARCH
>  ARCH := $(HOSTARCH)
>  endif
>  
> +SRCARCH := $(ARCH)
> +
> +# Additional ARCH settings for x86
> +ifeq ($(ARCH),i386)
> +        SRCARCH := x86
> +endif
> +ifeq ($(ARCH),x86_64)
> +        SRCARCH := x86
> +endif
> +
> +# Additional ARCH settings for sparc
> +ifeq ($(ARCH),sparc32)
> +       SRCARCH := sparc
> +endif
> +ifeq ($(ARCH),sparc64)
> +       SRCARCH := sparc
> +endif
> +
> +# Additional ARCH settings for sh
> +ifeq ($(ARCH),sh64)
> +       SRCARCH := sh
> +endif
> +
> +# Additional ARCH settings for tile
> +ifeq ($(ARCH),tilepro)
> +       SRCARCH := tile
> +endif
> +ifeq ($(ARCH),tilegx)
> +       SRCARCH := tile
> +endif
> +
>  LP64 := $(shell echo __LP64__ | ${CC} ${CFLAGS} -E -x c - | tail -n 1)
>  ifeq ($(LP64), 1)
>    IS_64_BIT := 1

Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree

[Josh Poimboeuf]

On Fri, Jul 22, 2016 at 04:36:55PM -0300, Arnaldo Carvalho de Melo wrote:
> Em Fri, Jul 22, 2016 at 02:19:20PM -0500, Josh Poimboeuf escreveu:
> > On Fri, Jul 22, 2016 at 11:37:39AM -0300, Arnaldo Carvalho de Melo wrote:
> > > Em Thu, Jul 21, 2016 at 10:41:18PM -0500, Josh Poimboeuf escreveu:
> > > > On Fri, Jul 22, 2016 at 09:23:02AM +1000, Stephen Rothwell wrote:
> > > > > It just looks like objtool was not written with cross compilation in
> > > > > mind?
> > >  
> > > > I don't know yet what the specific problem is, but objtool should work
> > > > fine in a cross-compiled environment.  It needs to be compiled with the
> > > > host (powerpc) compiler, but then it needs to disassemble target (x86)
> > > > files.  It worked fine before the bitsperlong.h files were merged.
> > > 
> > > So, trying to summarize from the various messages in this thread:
> > > 
> > > In Tue, Jul 19, 2016 at 01:26:08PM +1000, Stephen Rothwell wrote:
> > > 
> > > > It produces these errors (from the x86_64 allmodconfig build):
> > > >
> > > > In file included from
> > > > /home/sfr/next/next/tools/arch/x86/include/uapi/asm/bitsperlong.h:10:0,
> > > >                  from /usr/include/asm-generic/int-ll64.h:11,
> > > >                  from /usr/include/powerpc64le-linux-gnu/asm/types.h:27,
> > > >                  from /home/sfr/next/next/tools/include/linux/types.h:9,
> > > >                  from /home/sfr/next/next/tools/include/linux/list.h:4,
> > > >                  from elf.h:23,
> > > >                  from elf.c:30:
> > > > /home/sfr/next/next/tools/include/asm-generic/bitsperlong.h:13:2:
> > > > error: #error Inconsistent word size. Check asm/bitsperlong.h
> > > >  #error Inconsistent word size. Check asm/bitsperlong.h
> > > >   ^
> > > 
> > > So it starts at tools/arch/x86/include/uapi/asm/bitsperlong.h, and as
> > > you mention, this should've instead be using the host headers, i.e.:
> > > 
> > >    tools/arch/powerpc/include/uapi/asm/bitsperlong.h
> > > 
> > > Which it will if it uses HOSTARCH in tools/objtool/Makefile when setting
> > > up the header search path, I have two csets in my perf/core branch that
> > > fixes this, and that are equivalent to the last patch Stephen tried:
> > > 
> > >   $ git log --oneline -2
> > >   87f7dc54366a objtool: Use tools/scripts/Makefile.arch to get ARCH and HOSTARCH
> > >   0eec6770ab60 tools build: Add HOSTARCH Makefile variable
> > >   $ 
> > > 
> > > Ok, so now it uses the right file, see the whole sequence at the end of this
> > > e-mail, but it boils down to:
> > > 
> > > -----------------------------------------------------------------------------
> > > #if defined(__powerpc64__)
> > > # define __BITS_PER_LONG 64
> > > #else
> > > # define __BITS_PER_LONG 32
> > > #endif
> > > 
> > > #ifdef __SIZEOF_LONG__
> > > #define BITS_PER_LONG (__CHAR_BIT__ * __SIZEOF_LONG__)
> > > #else
> > > #define BITS_PER_LONG __WORDSIZE
> > > #endif
> > > 
> > > #if BITS_PER_LONG != __BITS_PER_LONG
> > > #error Inconsistent word size. Check asm/bitsperlong.h
> > > #endif
> > > -----------------------------------------------------------------------------
> > > 
> > > Which I think has no problems, right? The last problem reported ty Stephen now is:
> > > 
> > > In Fri, 22 Jul 2016 09:23:02 +1000, Stephen Rothwell wrote:
> > > 
> > > > That gets me this errors from the x86_64 allmodconfig build:
> > > 
> > > > tools/objtool/objtool-in.o: In function `decode_instructions':
> > > > tools/objtool/builtin-check.c:276: undefined reference to `arch_decode_instruction'
> > > 
> > > Should work, since ARCH should be x86 and then tools/objtool/Build will have
> > > this:
> > > 
> > > objtool-y += arch/$(ARCH)/
> > > 
> > > Turned into:
> > > 
> > > objtool-y += arch/x86/
> > > 
> > > Which will build tools/objtool/arch/x86/decode.c, that will provide that
> > > arch_decode_instruction() function :-\
> > > 
> > > I.e. with the two patches I mentioned, that are equivalent to the last patch I
> > > sent to Stephen for testing, we would end up with HOSTARCH=powerpc and
> > > ARCH=x86, no?
> > 
> > Thanks for spelling it out, that helped a lot.
> 
> Glad you liked it, I had to do it for my own sanity :-)
> 
> And something that gave me mixed feelings was an e-mail from the kbuild
> test bot that noticed my perf/core changes and said that the build was
> broken for "make ARCH=x86_64", so I had to reinstate this part:
> 
> ifeq ($(ARCH),x86_64)
> ARCH := x86
> endif
> 
> Because, as you say, 'make ARCH=x86' works :-\ I think it will not be
> needed with your patch, right? I'm checking your patch below right now,

Yeah, that shouldn't be needed with my patch.  I think either would
work, but my patch is more of a permanent solution.

-- 
Josh

Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree

[Arnaldo Carvalho de Melo]

Em Fri, Jul 22, 2016 at 02:44:17PM -0500, Josh Poimboeuf escreveu:
> On Fri, Jul 22, 2016 at 04:36:55PM -0300, Arnaldo Carvalho de Melo wrote:
> > Em Fri, Jul 22, 2016 at 02:19:20PM -0500, Josh Poimboeuf escreveu:
> > > On Fri, Jul 22, 2016 at 11:37:39AM -0300, Arnaldo Carvalho de Melo wrote:
> > > > I.e. with the two patches I mentioned, that are equivalent to the last patch I
> > > > sent to Stephen for testing, we would end up with HOSTARCH=powerpc and
> > > > ARCH=x86, no?

> > > Thanks for spelling it out, that helped a lot.

> > Glad you liked it, I had to do it for my own sanity :-)

> > And something that gave me mixed feelings was an e-mail from the kbuild
> > test bot that noticed my perf/core changes and said that the build was
> > broken for "make ARCH=x86_64", so I had to reinstate this part:

> > ifeq ($(ARCH),x86_64)
> > ARCH := x86
> > endif

> > Because, as you say, 'make ARCH=x86' works :-\ I think it will not be
> > needed with your patch, right? I'm checking your patch below right now,

> Yeah, that shouldn't be needed with my patch.  I think either would
> work, but my patch is more of a permanent solution.

Sure, I left it there because then we don't have bisection broke at that
fix I made, i.e. 'make ARCH=x86_64' works at that point too.

I applied your patch and will push it to Ingo, now we must cross our
fingers so that Stephen doesn't come back to us once more telling it is
still broken :o)

Best regards,

- Arnaldo

Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree

[Stephen Rothwell]

Hi Arnaldo,

On Fri, 22 Jul 2016 16:57:34 -0300 Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
>
> Em Fri, Jul 22, 2016 at 02:44:17PM -0500, Josh Poimboeuf escreveu:
> > On Fri, Jul 22, 2016 at 04:36:55PM -0300, Arnaldo Carvalho de Melo wrote:  
> > > Em Fri, Jul 22, 2016 at 02:19:20PM -0500, Josh Poimboeuf escreveu:  
> > > > On Fri, Jul 22, 2016 at 11:37:39AM -0300, Arnaldo Carvalho de Melo wrote:  
> > > > > I.e. with the two patches I mentioned, that are equivalent to the last patch I
> > > > > sent to Stephen for testing, we would end up with HOSTARCH=powerpc and
> > > > > ARCH=x86, no?  
> 
> > > > Thanks for spelling it out, that helped a lot.  
> 
> > > Glad you liked it, I had to do it for my own sanity :-)  
> 
> > > And something that gave me mixed feelings was an e-mail from the kbuild
> > > test bot that noticed my perf/core changes and said that the build was
> > > broken for "make ARCH=x86_64", so I had to reinstate this part:  
> 
> > > ifeq ($(ARCH),x86_64)
> > > ARCH := x86
> > > endif  
> 
> > > Because, as you say, 'make ARCH=x86' works :-\ I think it will not be
> > > needed with your patch, right? I'm checking your patch below right now,  
> 
> > Yeah, that shouldn't be needed with my patch.  I think either would
> > work, but my patch is more of a permanent solution.  
> 
> Sure, I left it there because then we don't have bisection broke at that
> fix I made, i.e. 'make ARCH=x86_64' works at that point too.
> 
> I applied your patch and will push it to Ingo, now we must cross our
> fingers so that Stephen doesn't come back to us once more telling it is
> still broken :o)

Unfortunately, this is what I get when I just build perf/core:

  DESCEND  objtool
  CC       /home/sfr/next/x86_64_allmodconfig/tools/objtool/builtin-check.o
  LD       /home/sfr/next/x86_64_allmodconfig/tools/objtool/objtool-in.o
Warning: objtool: x86 instruction decoder differs from kernel
  LINK     /home/sfr/next/x86_64_allmodconfig/tools/objtool/objtool
In file included from /home/sfr/next/next/arch/x86/include/uapi/asm/bitsperlong.h:10:0,
                 from /home/sfr/next/next/include/uapi/asm-generic/int-ll64.h:11,
                 from /home/sfr/next/next/include/uapi/asm-generic/types.h:6,
                 from /home/sfr/next/next/arch/x86/include/uapi/asm/types.h:4,
                 from /home/sfr/next/next/tools/include/linux/types.h:9,
                 from /home/sfr/next/next/include/uapi/linux/elf.h:4,
                 from /home/sfr/next/next/arch/x86/entry/vdso/vdso2c.c:66:
/home/sfr/next/next/tools/include/asm-generic/bitsperlong.h:13:2: error: #error Inconsistent word size. Check asm/bitsperlong.h
 #error Inconsistent word size. Check asm/bitsperlong.h
  ^

The be clear: this is a ppc64le hosted, x86_64 target cross build.

I than added the following patch, and the build finishes successfully.

From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Sat, 23 Jul 2016 14:35:40 +1000
Subject: [PATCH] x86: make the vdso2c compiler use the host architecture
 headers

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
 arch/x86/entry/vdso/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/entry/vdso/Makefile b/arch/x86/entry/vdso/Makefile
index 253b72eaade6..25e88c030c47 100644
--- a/arch/x86/entry/vdso/Makefile
+++ b/arch/x86/entry/vdso/Makefile
@@ -55,7 +55,7 @@ VDSO_LDFLAGS_vdso.lds = -m64 -Wl,-soname=linux-vdso.so.1 \
 $(obj)/vdso64.so.dbg: $(src)/vdso.lds $(vobjs) FORCE
 	$(call if_changed,vdso)
 
-HOST_EXTRACFLAGS += -I$(srctree)/tools/include -I$(srctree)/include/uapi -I$(srctree)/arch/x86/include/uapi
+HOST_EXTRACFLAGS += -I$(srctree)/tools/include -I$(srctree)/include/uapi -I$(srctree)/arch/$(SUBARCH)/include/uapi
 hostprogs-y			+= vdso2c
 
 quiet_cmd_vdso2c = VDSO2C  $@
-- 
2.8.1

There may be a more correct way to do this ...
-- 
Cheers,
Stephen Rothwell

Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree

[Andy Lutomirski]

On Fri, Jul 22, 2016 at 10:08 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Arnaldo,
>
> On Fri, 22 Jul 2016 16:57:34 -0300 Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
>>
>> Em Fri, Jul 22, 2016 at 02:44:17PM -0500, Josh Poimboeuf escreveu:
>> > On Fri, Jul 22, 2016 at 04:36:55PM -0300, Arnaldo Carvalho de Melo wrote:
>> > > Em Fri, Jul 22, 2016 at 02:19:20PM -0500, Josh Poimboeuf escreveu:
>> > > > On Fri, Jul 22, 2016 at 11:37:39AM -0300, Arnaldo Carvalho de Melo wrote:
>> > > > > I.e. with the two patches I mentioned, that are equivalent to the last patch I
>> > > > > sent to Stephen for testing, we would end up with HOSTARCH=powerpc and
>> > > > > ARCH=x86, no?
>>
>> > > > Thanks for spelling it out, that helped a lot.
>>
>> > > Glad you liked it, I had to do it for my own sanity :-)
>>
>> > > And something that gave me mixed feelings was an e-mail from the kbuild
>> > > test bot that noticed my perf/core changes and said that the build was
>> > > broken for "make ARCH=x86_64", so I had to reinstate this part:
>>
>> > > ifeq ($(ARCH),x86_64)
>> > > ARCH := x86
>> > > endif
>>
>> > > Because, as you say, 'make ARCH=x86' works :-\ I think it will not be
>> > > needed with your patch, right? I'm checking your patch below right now,
>>
>> > Yeah, that shouldn't be needed with my patch.  I think either would
>> > work, but my patch is more of a permanent solution.
>>
>> Sure, I left it there because then we don't have bisection broke at that
>> fix I made, i.e. 'make ARCH=x86_64' works at that point too.
>>
>> I applied your patch and will push it to Ingo, now we must cross our
>> fingers so that Stephen doesn't come back to us once more telling it is
>> still broken :o)
>
> Unfortunately, this is what I get when I just build perf/core:
>
>   DESCEND  objtool
>   CC       /home/sfr/next/x86_64_allmodconfig/tools/objtool/builtin-check.o
>   LD       /home/sfr/next/x86_64_allmodconfig/tools/objtool/objtool-in.o
> Warning: objtool: x86 instruction decoder differs from kernel
>   LINK     /home/sfr/next/x86_64_allmodconfig/tools/objtool/objtool
> In file included from /home/sfr/next/next/arch/x86/include/uapi/asm/bitsperlong.h:10:0,
>                  from /home/sfr/next/next/include/uapi/asm-generic/int-ll64.h:11,
>                  from /home/sfr/next/next/include/uapi/asm-generic/types.h:6,
>                  from /home/sfr/next/next/arch/x86/include/uapi/asm/types.h:4,
>                  from /home/sfr/next/next/tools/include/linux/types.h:9,
>                  from /home/sfr/next/next/include/uapi/linux/elf.h:4,
>                  from /home/sfr/next/next/arch/x86/entry/vdso/vdso2c.c:66:
> /home/sfr/next/next/tools/include/asm-generic/bitsperlong.h:13:2: error: #error Inconsistent word size. Check asm/bitsperlong.h
>  #error Inconsistent word size. Check asm/bitsperlong.h
>   ^
>
> The be clear: this is a ppc64le hosted, x86_64 target cross build.
>
> I than added the following patch, and the build finishes successfully.
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Sat, 23 Jul 2016 14:35:40 +1000
> Subject: [PATCH] x86: make the vdso2c compiler use the host architecture
>  headers

Aha, I missed that bit in the makefile.

Acked-by: Andy Lutomirski <luto@kernel.org>

>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  arch/x86/entry/vdso/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/x86/entry/vdso/Makefile b/arch/x86/entry/vdso/Makefile
> index 253b72eaade6..25e88c030c47 100644
> --- a/arch/x86/entry/vdso/Makefile
> +++ b/arch/x86/entry/vdso/Makefile
> @@ -55,7 +55,7 @@ VDSO_LDFLAGS_vdso.lds = -m64 -Wl,-soname=linux-vdso.so.1 \
>  $(obj)/vdso64.so.dbg: $(src)/vdso.lds $(vobjs) FORCE
>         $(call if_changed,vdso)
>
> -HOST_EXTRACFLAGS += -I$(srctree)/tools/include -I$(srctree)/include/uapi -I$(srctree)/arch/x86/include/uapi
> +HOST_EXTRACFLAGS += -I$(srctree)/tools/include -I$(srctree)/include/uapi -I$(srctree)/arch/$(SUBARCH)/include/uapi
>  hostprogs-y                    += vdso2c
>
>  quiet_cmd_vdso2c = VDSO2C  $@
> --
> 2.8.1
>
> There may be a more correct way to do this ...
> --
>Can  Cheers,
> Stephen Rothwell



-- 
Andy Lutomirski
AMA Capital Management, LLC

Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree

[Arnaldo Carvalho de Melo]

Em Sat, Jul 23, 2016 at 03:08:45PM +1000, Stephen Rothwell escreveu:
> On Fri, 22 Jul 2016 16:57:34 -0300 Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
> > I applied your patch and will push it to Ingo, now we must cross our
> > fingers so that Stephen doesn't come back to us once more telling it is
> > still broken :o)
 
> Unfortunately, this is what I get when I just build perf/core:
 
>   DESCEND  objtool
>   CC       /home/sfr/next/x86_64_allmodconfig/tools/objtool/builtin-check.o

Cool! objtool is fixed, we're not at a different tool using those
headers, and your patch fixes it, I see Andy acked it, I'll merge this
and push to Ingo,

Thanks,

- Arnaldo

>   LD       /home/sfr/next/x86_64_allmodconfig/tools/objtool/objtool-in.o
> Warning: objtool: x86 instruction decoder differs from kernel
>   LINK     /home/sfr/next/x86_64_allmodconfig/tools/objtool/objtool
> In file included from /home/sfr/next/next/arch/x86/include/uapi/asm/bitsperlong.h:10:0,
>                  from /home/sfr/next/next/include/uapi/asm-generic/int-ll64.h:11,
>                  from /home/sfr/next/next/include/uapi/asm-generic/types.h:6,
>                  from /home/sfr/next/next/arch/x86/include/uapi/asm/types.h:4,
>                  from /home/sfr/next/next/tools/include/linux/types.h:9,
>                  from /home/sfr/next/next/include/uapi/linux/elf.h:4,
>                  from /home/sfr/next/next/arch/x86/entry/vdso/vdso2c.c:66:
> /home/sfr/next/next/tools/include/asm-generic/bitsperlong.h:13:2: error: #error Inconsistent word size. Check asm/bitsperlong.h
>  #error Inconsistent word size. Check asm/bitsperlong.h
>   ^
> 
> The be clear: this is a ppc64le hosted, x86_64 target cross build.
> 
> I than added the following patch, and the build finishes successfully.
> 
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Sat, 23 Jul 2016 14:35:40 +1000
> Subject: [PATCH] x86: make the vdso2c compiler use the host architecture
>  headers
> 
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
>  arch/x86/entry/vdso/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/x86/entry/vdso/Makefile b/arch/x86/entry/vdso/Makefile
> index 253b72eaade6..25e88c030c47 100644
> --- a/arch/x86/entry/vdso/Makefile
> +++ b/arch/x86/entry/vdso/Makefile
> @@ -55,7 +55,7 @@ VDSO_LDFLAGS_vdso.lds = -m64 -Wl,-soname=linux-vdso.so.1 \
>  $(obj)/vdso64.so.dbg: $(src)/vdso.lds $(vobjs) FORCE
>  	$(call if_changed,vdso)
>  
> -HOST_EXTRACFLAGS += -I$(srctree)/tools/include -I$(srctree)/include/uapi -I$(srctree)/arch/x86/include/uapi
> +HOST_EXTRACFLAGS += -I$(srctree)/tools/include -I$(srctree)/include/uapi -I$(srctree)/arch/$(SUBARCH)/include/uapi
>  hostprogs-y			+= vdso2c
>  
>  quiet_cmd_vdso2c = VDSO2C  $@
> -- 
> 2.8.1
> 
> There may be a more correct way to do this ...
> -- 
> Cheers,
> Stephen Rothwell

[tip:perf/core] objtool: Always use host headers

[tip-bot for Arnaldo Carvalho de Melo]

Commit-ID:  0cf6eb603b83ea386f26363b5b12e64297822bb1
Gitweb:     http://git.kernel.org/tip/0cf6eb603b83ea386f26363b5b12e64297822bb1
Author:     Arnaldo Carvalho de Melo <acme@redhat.com>
AuthorDate: Fri, 22 Jul 2016 16:28:46 -0300
Committer:  Arnaldo Carvalho de Melo <acme@redhat.com>
CommitDate: Fri, 22 Jul 2016 16:28:46 -0300

objtool: Always use host headers

>From a conversation with Josh:

>From http://lkml.kernel.org/r/20160722034118.guckaniobf3f7czc@treble :

It needs to be compiled with the host (powerpc) compiler, but then it
needs to disassemble target (x86) files.

 ----

So use HOSTARCH instead of ARCH.

Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Wang Nan <wangnan0@huawei.com>
Link: http://lkml.kernel.org/r/20160722034118.guckaniobf3f7czc@treble
Link: http://lkml.kernel.org/n/tip-le1m1yzxnfpt3msbblu40nm8@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
---
 tools/objtool/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/objtool/Makefile b/tools/objtool/Makefile
index 988129c..91b5f98 100644
--- a/tools/objtool/Makefile
+++ b/tools/objtool/Makefile
@@ -24,7 +24,7 @@ OBJTOOL_IN := $(OBJTOOL)-in.o
 
 all: $(OBJTOOL)
 
-INCLUDES := -I$(srctree)/tools/include -I$(srctree)/tools/arch/$(ARCH)/include/uapi
+INCLUDES := -I$(srctree)/tools/include -I$(srctree)/tools/arch/$(HOSTARCH)/include/uapi
 CFLAGS   += -Wall -Werror $(EXTRA_WARNINGS) -fomit-frame-pointer -O2 -g $(INCLUDES)
 LDFLAGS  += -lelf $(LIBSUBCMD)
 

[tip:perf/core] tools build: Fix objtool build with ARCH=x86_64

[tip-bot for Josh Poimboeuf]

Commit-ID:  60cbdf5d051d4f4db23d267d511ca241d4be7c0d
Gitweb:     http://git.kernel.org/tip/60cbdf5d051d4f4db23d267d511ca241d4be7c0d
Author:     Josh Poimboeuf <jpoimboe@redhat.com>
AuthorDate: Fri, 22 Jul 2016 14:19:20 -0500
Committer:  Arnaldo Carvalho de Melo <acme@redhat.com>
CommitDate: Fri, 22 Jul 2016 16:37:44 -0300

tools build: Fix objtool build with ARCH=x86_64

The objtool build fails in a cross-compiled environment on a non-x86
host with "ARCH=x86_64":

  tools/objtool/objtool-in.o: In function `decode_instructions':
  tools/objtool/builtin-check.c:276: undefined reference to `arch_decode_instruction'

We could override the ARCH environment variable and change it back to
x86, similar to what the objtool Makefile was doing before; but it's
tricky to override environment variables consistently.

Instead, take a similar approach used by the Linux top-level Makefile
and introduce a SRCARCH Makefile variable which evaluates to "x86" when
ARCH is either "x86_64" or "x86".

Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20160722191920.ej62fnspnqurbaa7@treble
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
---
 tools/objtool/Build         |  2 +-
 tools/objtool/Makefile      |  2 +-
 tools/scripts/Makefile.arch | 32 ++++++++++++++++++++++++++++++++
 3 files changed, 34 insertions(+), 2 deletions(-)

diff --git a/tools/objtool/Build b/tools/objtool/Build
index 2457916..d6cdece 100644
--- a/tools/objtool/Build
+++ b/tools/objtool/Build
@@ -1,4 +1,4 @@
-objtool-y += arch/$(ARCH)/
+objtool-y += arch/$(SRCARCH)/
 objtool-y += builtin-check.o
 objtool-y += elf.o
 objtool-y += special.o
diff --git a/tools/objtool/Makefile b/tools/objtool/Makefile
index 91b5f98..0b43770 100644
--- a/tools/objtool/Makefile
+++ b/tools/objtool/Makefile
@@ -33,7 +33,7 @@ elfshdr := $(shell echo '\#include <libelf.h>' | $(CC) $(CFLAGS) -x c -E - | gre
 CFLAGS += $(if $(elfshdr),,-DLIBELF_USE_DEPRECATED)
 
 AWK = awk
-export srctree OUTPUT CFLAGS ARCH AWK
+export srctree OUTPUT CFLAGS SRCARCH AWK
 include $(srctree)/tools/build/Makefile.include
 
 $(OBJTOOL_IN): fixdep FORCE
diff --git a/tools/scripts/Makefile.arch b/tools/scripts/Makefile.arch
index 887321c..ad85b92 100644
--- a/tools/scripts/Makefile.arch
+++ b/tools/scripts/Makefile.arch
@@ -5,10 +5,42 @@ HOSTARCH := $(shell uname -m | sed -e s/i.86/x86/ -e s/x86_64/x86/ \
                                   -e s/ppc.*/powerpc/ -e s/mips.*/mips/ \
                                   -e s/sh[234].*/sh/ -e s/aarch64.*/arm64/ \
                                   -e s/tile.*/tile/ )
+
 ifndef ARCH
 ARCH := $(HOSTARCH)
 endif
 
+SRCARCH := $(ARCH)
+
+# Additional ARCH settings for x86
+ifeq ($(ARCH),i386)
+        SRCARCH := x86
+endif
+ifeq ($(ARCH),x86_64)
+        SRCARCH := x86
+endif
+
+# Additional ARCH settings for sparc
+ifeq ($(ARCH),sparc32)
+       SRCARCH := sparc
+endif
+ifeq ($(ARCH),sparc64)
+       SRCARCH := sparc
+endif
+
+# Additional ARCH settings for sh
+ifeq ($(ARCH),sh64)
+       SRCARCH := sh
+endif
+
+# Additional ARCH settings for tile
+ifeq ($(ARCH),tilepro)
+       SRCARCH := tile
+endif
+ifeq ($(ARCH),tilegx)
+       SRCARCH := tile
+endif
+
 LP64 := $(shell echo __LP64__ | ${CC} ${CFLAGS} -E -x c - | tail -n 1)
 ifeq ($(LP64), 1)
   IS_64_BIT := 1

[tip:perf/core] x86: Make the vdso2c compiler use the host architecture headers

[tip-bot for Stephen Rothwell]

Commit-ID:  d51306f1a3bc0e3a7b86d8f2b2dedf34b356d3dd
Gitweb:     http://git.kernel.org/tip/d51306f1a3bc0e3a7b86d8f2b2dedf34b356d3dd
Author:     Stephen Rothwell <sfr@canb.auug.org.au>
AuthorDate: Sat, 23 Jul 2016 14:35:40 +1000
Committer:  Arnaldo Carvalho de Melo <acme@redhat.com>
CommitDate: Mon, 25 Jul 2016 10:02:21 -0300

x86: Make the vdso2c compiler use the host architecture headers

To be clear: this is a ppc64le hosted, x86_64 target cross build.

Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
Acked-by: Andy Lutomirski <luto@kernel.org>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20160723150845.3af8e452@canb.auug.org.au
Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
---
 arch/x86/entry/vdso/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/entry/vdso/Makefile b/arch/x86/entry/vdso/Makefile
index 253b72e..25e88c0 100644
--- a/arch/x86/entry/vdso/Makefile
+++ b/arch/x86/entry/vdso/Makefile
@@ -55,7 +55,7 @@ VDSO_LDFLAGS_vdso.lds = -m64 -Wl,-soname=linux-vdso.so.1 \
 $(obj)/vdso64.so.dbg: $(src)/vdso.lds $(vobjs) FORCE
 	$(call if_changed,vdso)
 
-HOST_EXTRACFLAGS += -I$(srctree)/tools/include -I$(srctree)/include/uapi -I$(srctree)/arch/x86/include/uapi
+HOST_EXTRACFLAGS += -I$(srctree)/tools/include -I$(srctree)/include/uapi -I$(srctree)/arch/$(SUBARCH)/include/uapi
 hostprogs-y			+= vdso2c
 
 quiet_cmd_vdso2c = VDSO2C  $@