linux-next: build failure after merge of the luto-misc tree
Subsystems (5)
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 <[email protected]>
Date: Fri, 15 Jul 2016 16:58:25 +1000
Subject: [PATCH] tools: partial revert of 2a00f026a15d "tools: Fix up
BITS_PER_LONG setting"
--- tools/include/asm-generic/bitsperlong.h | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-)
tools/include/asm-generic/bitsperlong.h +5 -1
@@ -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
Signature · 5 lines
2.8.1 -- Cheers, Stephen Rothwell
Peter Zijlstra
maintainerQuoted 5 lines · Stephen Rothwell
interacting with commit
2a00f026a15d("tools: Fix upBITS_PER_LONGsetting")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)
tools/include/asm-generic/bitsperlong.h +1 -32
@@ -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 */
Peter Zijlstra
maintainerQuoted 20 lines · Peter Zijlstra
Quoted 5 lines · Stephen Rothwell
interacting with commit
2a00f026a15d("tools: Fix upBITS_PER_LONGsetting")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__
#defineCONFIG_64BIT
#else
#defineCONFIG_32BIT
#endif
Quoted 3 lines
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.
Em Fri, Jul 15, 2016 at 09:31:19AM +0200, Peter Zijlstra escreveu:
Quoted 21 lines · Peter Zijlstra
Quoted 20 lines · Stephen Rothwell
Quoted 5 lines
interacting with commit
2a00f026a15d("tools: Fix upBITS_PER_LONGsetting")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__
#defineCONFIG_64BIT
#else
#defineCONFIG_32BIT
#endif
Quoted 6 lines
Quoted 3 lines
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
Em Fri, Jul 15, 2016 at 12:09:03PM -0300, Arnaldo Carvalho de Melo escreveu:
Quoted 24 lines
Em Fri, Jul 15, 2016 at 09:31:19AM +0200, Peter Zijlstra escreveu:
Quoted 23 lines · Peter Zijlstra
Quoted 22 lines · Stephen Rothwell
Quoted 5 lines
interacting with commit
2a00f026a15d("tools: Fix upBITS_PER_LONGsetting")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__
#defineCONFIG_64BIT
#else
#defineCONFIG_32BIT
#endifAll GCC versions I checked have
__CHAR_BIT__and__SIZEOF_LONG__.
Quoted 8 lines
Quoted 4 lines
Quoted 1 line
(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
Peter Zijlstra
maintainerQuoted 5 lines · Arnaldo Carvalho de Melo
Seems ok, but I'll reinstate this:
#if
BITS_PER_LONG!=__BITS_PER_LONG
#error Inconsistent word size. Checkasm/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?
Em Fri, Jul 15, 2016 at 05:29:37PM +0200, Peter Zijlstra escreveu:
Quoted 7 lines · Arnaldo Carvalho de Melo
Quoted 5 lines
Seems ok, but I'll reinstate this:
#if
BITS_PER_LONG!=__BITS_PER_LONG
#error Inconsistent word size. Checkasm/bitsperlong.h#endif
Quoted 7 lines
Confuses me; why do we have two?
Why not then do:
#define
BITS_PER_LONG__BITS_PER_LONGand 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
Arnaldo Carvalho de Melo
Tested-byEm Fri, Jul 15, 2016 at 12:24:36PM -0300, Arnaldo Carvalho de Melo escreveu:
Quoted 14 lines
Em Fri, Jul 15, 2016 at 12:09:03PM -0300, Arnaldo Carvalho de Melo escreveu:
Quoted 4 lines
Em Fri, Jul 15, 2016 at 09:31:19AM +0200, Peter Zijlstra escreveu:
Quoted 2 lines · Peter Zijlstra
Quoted 1 line
All GCC versions I checked have
__CHAR_BIT__and__SIZEOF_LONG__.Quoted 8 lines
Quoted 4 lines
Quoted 1 line
(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...
Quoted 7 lines
Seems ok, but I'll reinstate this:
#if
BITS_PER_LONG!=__BITS_PER_LONG
#error Inconsistent word size. Checkasm/bitsperlong.h#endifAnd 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 <[email protected]> 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.
tools/include/asm-generic/bitsperlong.h +1 -24
@@ -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
Peter Zijlstra
maintainerQuoted 1 line · Arnaldo Carvalho de Melo
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.
Quoted 10 lines
commit
a08cc3e6f7bb965672a3ff60f98d0dbbc5334ee7Author: Peter Zijlstra <[email protected]> Date: Fri Jul 15 12:38:18 2016 -0300tools: Simplify
BITS_PER_LONGdefineDo it using (
__CHAR_BIT__*__SIZEOF_LONG__), simpler, works everywhere, reduces the complexity by ditchingCONFIG_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.
Em Fri, Jul 15, 2016 at 05:49:30PM +0200, Peter Zijlstra escreveu:
Quoted 5 lines · Arnaldo Carvalho de Melo
Quoted 1 line
Ok, same results, it works, queuing this one, ack?
Sure. Although I'm still somewhat puzzled by the duplicated effort of
__BITS_PER_LONGandBITS_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
Quoted 13 lines
Quoted 10 lines
commit
a08cc3e6f7bb965672a3ff60f98d0dbbc5334ee7Author: Peter Zijlstra <[email protected]> Date: Fri Jul 15 12:38:18 2016 -0300tools: Simplify
BITS_PER_LONGdefineDo it using (
__CHAR_BIT__*__SIZEOF_LONG__), simpler, works everywhere, reduces the complexity by ditchingCONFIG_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.
H. Peter Anvin
reviewerQuoted 4 lines · Arnaldo Carvalho de Melo
Em Fri, Jul 15, 2016 at 05:49:30PM +0200, Peter Zijlstra escreveu:
Quoted 3 lines · Arnaldo Carvalho de Melo
Quoted 1 line
Ok, same results, it works, queuing this one, ack?
Quoted 8 lines
Quoted 2 lines
Sure. Although I'm still somewhat puzzled by the duplicated effort of
__BITS_PER_LONGandBITS_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
Hi Arnaldo,
Quoted 3 lines · On Fri, 15 Jul 2016 12:43:26 -0300 Arnaldo Carvalho de Melo <[email protected]>…
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).
Signature · 2 lines
Cheers, Stephen Rothwell
Quoted 10 lines · Stephen Rothwell
Hi Arnaldo,
Quoted 3 lines · On Fri, 15 Jul 2016 12:43:26 -0300 Arnaldo Carvalho de Melo <[email protected]>…
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:
coupled with a change to make vdso2c or, more generally, hostprogs-y use USERINCLUDE would help.
--Andy
Em Mon, Jul 18, 2016 at 01:04:34PM -0700, Andy Lutomirski escreveu:
Quoted 9 lines · Stephen Rothwell
Quoted 8 lines · On Fri, 15 Jul 2016 12:43:26 -0300 Arnaldo Carvalho de Melo <[email protected]>…
Quoted 3 lines
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?
Quoted 9 lines
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:
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
Hi Arnaldo,
Quoted 8 lines · On Mon, 18 Jul 2016 17:36:34 -0300 Arnaldo Carvalho de Melo <[email protected]>…
Em Mon, Jul 18, 2016 at 01:04:34PM -0700, Andy Lutomirski escreveu:
Quoted 5 lines · Stephen Rothwell
Quoted 4 lines · On Fri, 15 Jul 2016 12:43:26 -0300 Arnaldo Carvalho de Melo <[email protected]>…
Quoted 3 lines
Ok, same results, it works, queuing this one, ack? Stephen, does it work for you?
Quoted 6 lines
Quoted 3 lines
Quoted 3 lines
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.
Signature · 2 lines
Cheers, Stephen Rothwell
Em Tue, Jul 19, 2016 at 08:22:35AM +1000, Stephen Rothwell escreveu:
Quoted 18 lines
Hi Arnaldo,
Quoted 8 lines · On Mon, 18 Jul 2016 17:36:34 -0300 Arnaldo Carvalho de Melo <[email protected]>…
Em Mon, Jul 18, 2016 at 01:04:34PM -0700, Andy Lutomirski escreveu:
Quoted 5 lines · Stephen Rothwell
Quoted 4 lines · On Fri, 15 Jul 2016 12:43:26 -0300 Arnaldo Carvalho de Melo <[email protected]>…
Quoted 3 lines
Ok, same results, it works, queuing this one, ack? Stephen, does it work for you?
Quoted 6 lines
Quoted 3 lines
Quoted 3 lines
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?
Quoted 6 lines
I am using a
x86_64compiler (target) on powerpc64le (host). Yesterday, thex86_64allmodconfig 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
Hi Arnaldo,
Quoted 5 lines · On Mon, 18 Jul 2016 20:41:32 -0300 Arnaldo Carvalho de Melo <[email protected]>…
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.
Signature · 2 lines
Cheers, Stephen Rothwell
Em Tue, Jul 19, 2016 at 10:26:29AM +1000, Stephen Rothwell escreveu:
Quoted 9 lines · On Mon, 18 Jul 2016 20:41:32 -0300 Arnaldo Carvalho de Melo <[email protected]>…
Quoted 4 lines
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
Hi Arnaldo,
Quoted 16 lines · On Mon, 18 Jul 2016 21:39:06 -0300 Arnaldo Carvalho de Melo <[email protected]>…
Em Tue, Jul 19, 2016 at 10:26:29AM +1000, Stephen Rothwell escreveu:
Quoted 3 lines
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..ae3c14a028ed10552803b68276b6833295ba18cfae3c14a028ed10552803b68276b6833295ba18cftools: Copylinux/{hash,poison}.hand check for drift3aa0042769313b720142c0ef8514dac389e14ebeperf tools: Removeinclude/linux/list.hfrom perf's MANIFESTde1e17b1d0c81be472039798698b517c8a68b516tools: Copy the bitops files accessed from the kernel and check for driftad430729ae00dd63f7dcadbeb638e589bc03b5a3Remove: kernel unistd*h files from perf's MANIFEST, not usede0643c4e9fdb2e77ab83ca596460e2c9c15728aaperf tools: Removetools/perf/util/include/linux/const.h7e3f36411342a54f1981fa97b43550b8406a3d69perf tools: Removetools/perf/util/include/asm/byteorder.h14f0652b4fbebd0b05da36a06b17ac6d4d87a8f8perf tools: Add missinglinux/compiler.hinclude toperf-sys.h
Quoted 6 lines
Available on my repo/branch:
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.gitperf/coreI 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.
Signature · 2 lines
Cheers, Stephen Rothwell
Em Tue, Jul 19, 2016 at 01:26:08PM +1000, Stephen Rothwell escreveu:
Quoted 39 lines
Hi Arnaldo,
Quoted 16 lines · On Mon, 18 Jul 2016 21:39:06 -0300 Arnaldo Carvalho de Melo <[email protected]>…
Em Tue, Jul 19, 2016 at 10:26:29AM +1000, Stephen Rothwell escreveu:
Quoted 3 lines
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..ae3c14a028ed10552803b68276b6833295ba18cfae3c14a028ed10552803b68276b6833295ba18cftools: Copylinux/{hash,poison}.hand check for drift3aa0042769313b720142c0ef8514dac389e14ebeperf tools: Removeinclude/linux/list.hfrom perf's MANIFESTde1e17b1d0c81be472039798698b517c8a68b516tools: Copy the bitops files accessed from the kernel and check for driftad430729ae00dd63f7dcadbeb638e589bc03b5a3Remove: kernel unistd*h files from perf's MANIFEST, not usede0643c4e9fdb2e77ab83ca596460e2c9c15728aaperf tools: Removetools/perf/util/include/linux/const.h7e3f36411342a54f1981fa97b43550b8406a3d69perf tools: Removetools/perf/util/include/asm/byteorder.h14f0652b4fbebd0b05da36a06b17ac6d4d87a8f8perf tools: Add missinglinux/compiler.hinclude toperf-sys.hQuoted 6 lines
Available on my repo/branch:
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.gitperf/coreI 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_64allmodconfig 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:
Quoted 8 lines
/home/sfr/next/next/tools/include/asm-generic/bitsperlong.h:13:2: error: #error Inconsistent word size. Checkasm/bitsperlong.h
#error Inconsistent word size. Checkasm/bitsperlong.h
^(and more similar).
I have applied my patch from yesterday ("tools: Simplify
__BITS_PER_LONGdefine"), 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
Em Tue, Jul 19, 2016 at 09:54:43AM -0300, Arnaldo Carvalho de Melo escreveu:
Quoted 40 lines
Em Tue, Jul 19, 2016 at 01:26:08PM +1000, Stephen Rothwell escreveu:
Quoted 39 lines · On Mon, 18 Jul 2016 21:39:06 -0300 Arnaldo Carvalho de Melo <[email protected]>…
Quoted 14 lines
Em Tue, Jul 19, 2016 at 10:26:29AM +1000, Stephen Rothwell escreveu:
Quoted 3 lines
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..ae3c14a028ed10552803b68276b6833295ba18cfae3c14a028ed10552803b68276b6833295ba18cftools: Copylinux/{hash,poison}.hand check for drift3aa0042769313b720142c0ef8514dac389e14ebeperf tools: Removeinclude/linux/list.hfrom perf's MANIFESTde1e17b1d0c81be472039798698b517c8a68b516tools: Copy the bitops files accessed from the kernel and check for driftad430729ae00dd63f7dcadbeb638e589bc03b5a3Remove: kernel unistd*h files from perf's MANIFEST, not usede0643c4e9fdb2e77ab83ca596460e2c9c15728aaperf tools: Removetools/perf/util/include/linux/const.h7e3f36411342a54f1981fa97b43550b8406a3d69perf tools: Removetools/perf/util/include/asm/byteorder.h14f0652b4fbebd0b05da36a06b17ac6d4d87a8f8perf tools: Add missinglinux/compiler.hinclude toperf-sys.hQuoted 6 lines
Available on my repo/branch:
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.gitperf/coreI 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_64allmodconfig 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. Checkasm/bitsperlong.h
#error Inconsistent word size. Checkasm/bitsperlong.h
^
Quoted 7 lines
Quoted 4 lines
(and more similar).
I have applied my patch from yesterday ("tools: Simplify
__BITS_PER_LONGdefine"), and will continue on.Ok, I'm trying the other way around, i.e. building a ppc64 kernel on a
x86_64machine, 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?
tools/include/asm-generic/bitsperlong.h +3 -0
@@ -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
Hi Arnaldo,
Quoted 3 lines · On Tue, 19 Jul 2016 14:45:51 -0300 Arnaldo Carvalho de Melo <[email protected]>…
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.
Quoted 10 lines
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?tools/include/asm-generic/bitsperlong.h +0
-0
tools/include/asm-generic/bitsperlong.h line 17
Quoted 8 lines
tools/include/asm-generic/bitsperlong.h +3
-0@@ -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)
Signature · 2 lines
Cheers, Stephen Rothwell
Hi Arnaldo,
Quoted 30 lines · On Wed, 20 Jul 2016 09:21:57 +1000 Stephen Rothwell <[email protected]>…
Quoted 3 lines · On Tue, 19 Jul 2016 14:45:51 -0300 Arnaldo Carvalho de Melo <[email protected]>…
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.
Quoted 10 lines
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?tools/include/asm-generic/bitsperlong.h +0
-0tools/include/asm-generic/bitsperlong.h line 17
Quoted 8 lines
tools/include/asm-generic/bitsperlong.h +3
-0@@ -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:
Quoted 8 lines
/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:
tools/arch/x86/include/uapi/asm/bitsperlong.h +6 -0
@@ -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"
Signature · 2 lines
Cheers, Stephen Rothwell
Em Wed, Jul 20, 2016 at 09:53:33AM +1000, Stephen Rothwell escreveu:
Quoted 38 lines · On Wed, 20 Jul 2016 09:21:57 +1000 Stephen Rothwell <[email protected]>…
Quoted 11 lines · On Tue, 19 Jul 2016 14:45:51 -0300 Arnaldo Carvalho de Melo <[email protected]>…
Review
Quoted 6 lines
#if
BITS_PER_LONG!=__BITS_PER_LONG(quoted diff) +3
-0+#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 #endifI added those three lines to the file (just in yesterday's linux-next was easiest) and got this:
Quoted 7 lines
/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.htools/arch/x86/include/uapi/asm/bitsperlong.h +6
-0@@ -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:
Quoted 2 lines
/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
Quoted 37 lines · Arnaldo Carvalho de Melo
Em Wed, Jul 20, 2016 at 09:53:33AM +1000, Stephen Rothwell escreveu:
Quoted 35 lines · On Wed, 20 Jul 2016 09:21:57 +1000 Stephen Rothwell <[email protected]>…
Quoted 11 lines · On Tue, 19 Jul 2016 14:45:51 -0300 Arnaldo Carvalho de Melo <[email protected]>…
Review
Quoted 6 lines
#if
BITS_PER_LONG!=__BITS_PER_LONG(quoted diff) +3
-0+#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 #endifI added those three lines to the file (just in yesterday's linux-next was easiest) and got this:
Quoted 7 lines
/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.htools/arch/x86/include/uapi/asm/bitsperlong.h +6
-0@@ -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
Quoted 8 lines
Quoted 4 lines
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
Quoted 1 line
- Arnaldo
Signature · 2 lines
Andy Lutomirski AMA Capital Management, LLC
Em Tue, Jul 19, 2016 at 07:57:24PM -0700, Andy Lutomirski escreveu:
Quoted 48 lines
Quoted 37 lines · Arnaldo Carvalho de Melo
Em Wed, Jul 20, 2016 at 09:53:33AM +1000, Stephen Rothwell escreveu:
Quoted 35 lines · On Wed, 20 Jul 2016 09:21:57 +1000 Stephen Rothwell <[email protected]>…
Quoted 11 lines · On Tue, 19 Jul 2016 14:45:51 -0300 Arnaldo Carvalho de Melo <[email protected]>…
Review
Quoted 6 lines
#if
BITS_PER_LONG!=__BITS_PER_LONG(quoted diff) +3
-0+#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 #endifI added those three lines to the file (just in yesterday's linux-next was easiest) and got this:
Quoted 7 lines
/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.htools/arch/x86/include/uapi/asm/bitsperlong.h +6
-0@@ -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 Quoted 8 lines
Quoted 4 lines
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.
Quoted 6 lines
This is still vdso2c, right? It's a hostprog.
This stuff is utterly screwed up. We're building a hostprog for an
x86_64kernel 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
Hi Arnaldo,
Quoted 52 lines · On Wed, 20 Jul 2016 00:09:24 -0300 Arnaldo Carvalho de Melo <[email protected]>…
Em Tue, Jul 19, 2016 at 07:57:24PM -0700, Andy Lutomirski escreveu:
Quoted 50 lines
Quoted 37 lines · Arnaldo Carvalho de Melo
Em Wed, Jul 20, 2016 at 09:53:33AM +1000, Stephen Rothwell escreveu:
Quoted 35 lines · On Wed, 20 Jul 2016 09:21:57 +1000 Stephen Rothwell <[email protected]>…
Quoted 11 lines · On Tue, 19 Jul 2016 14:45:51 -0300 Arnaldo Carvalho de Melo <[email protected]>…
Review
Quoted 6 lines
#if
BITS_PER_LONG!=__BITS_PER_LONG(quoted diff) +3
-0+#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 #endifI added those three lines to the file (just in yesterday's linux-next was easiest) and got this:
Quoted 7 lines
/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.htools/arch/x86/include/uapi/asm/bitsperlong.h +6
-0@@ -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 Quoted 8 lines
Quoted 4 lines
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.
Quoted 7 lines
Quoted 4 lines
This stuff is utterly screwed up. We're building a hostprog for an
x86_64kernel 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,
Signature · 2 lines
Cheers, Stephen Rothwell
Hi Arnaldo,
Quoted 3 lines · On Tue, 19 Jul 2016 23:52:02 -0300 Arnaldo Carvalho de Melo <[email protected]>…
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).
Signature · 2 lines
Cheers, Stephen Rothwell
Em Thu, Jul 21, 2016 at 09:29:50AM +1000, Stephen Rothwell escreveu:
Quoted 8 lines
Hi Arnaldo,
Quoted 3 lines · On Tue, 19 Jul 2016 23:52:02 -0300 Arnaldo Carvalho de Melo <[email protected]>…
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?
tools/objtool/Makefile +9 -5
@@ -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)
Hi Arnaldo,
Quoted 37 lines · On Thu, 21 Jul 2016 10:12:48 -0300 Arnaldo Carvalho de Melo <[email protected]>…
Em Thu, Jul 21, 2016 at 09:29:50AM +1000, Stephen Rothwell escreveu:
Quoted 8 lines
Hi Arnaldo,
Quoted 3 lines · On Tue, 19 Jul 2016 23:52:02 -0300 Arnaldo Carvalho de Melo <[email protected]>…
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?
tools/objtool/Makefile +8
-4@@ -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
tools/objtool/Makefile OBJTOOL_IN := $(OBJTOOL)-in.o · line 36
Quoted 8 lines
tools/objtool/Makefile +1
-1@@ -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.
Signature · 2 lines
Cheers, Stephen Rothwell
Quoted 51 lines · Stephen Rothwell
Hi Arnaldo,
Quoted 37 lines · On Thu, 21 Jul 2016 10:12:48 -0300 Arnaldo Carvalho de Melo <[email protected]>…
Em Thu, Jul 21, 2016 at 09:29:50AM +1000, Stephen Rothwell escreveu:
Quoted 8 lines
Hi Arnaldo,
Quoted 3 lines · On Tue, 19 Jul 2016 23:52:02 -0300 Arnaldo Carvalho de Melo <[email protected]>…
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?
tools/objtool/Makefile +8
-4@@ -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 compilertools/objtool/Makefile OBJTOOL_IN := $(OBJTOOL)-in.o · line 36
Quoted 8 lines
tools/objtool/Makefile +1
-1@@ -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_64allmodconfig build:
Quoted 5 lines
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.
Quoted 3 lines
It seems to build and run OK when you remove the test that checks that
BITS_PER_LONGand__BITS_PER_LONGare the same, but I have no idea if it getting the desired results.
Signature · 1 line
Josh
Em Thu, Jul 21, 2016 at 10:41:18PM -0500, Josh Poimboeuf escreveu:
Quoted 8 lines · Stephen Rothwell
Quoted 2 lines
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.hfiles were merged.
So, trying to summarize from the various messages in this thread:
Quoted 10 lines · Stephen Rothwell
It produces these errors (from the
x86_64allmodconfig 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:
Quoted 4 lines
/home/sfr/next/next/tools/include/asm-generic/bitsperlong.h:13:2:
error: #error Inconsistent word size. Checkasm/bitsperlong.h
#error Inconsistent word size. Checkasm/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:
Quoted 4 lines · Stephen Rothwell
That gets me this errors from the
x86_64allmodconfig 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]$
Quoted 80 lines · Arnaldo Carvalho de Melo
Em Thu, Jul 21, 2016 at 10:41:18PM -0500, Josh Poimboeuf escreveu:
Quoted 8 lines · Stephen Rothwell
Quoted 2 lines
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.hfiles were merged.So, trying to summarize from the various messages in this thread:
Quoted 10 lines · Stephen Rothwell
It produces these errors (from the
x86_64allmodconfig 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:Quoted 4 lines
/home/sfr/next/next/tools/include/asm-generic/bitsperlong.h:13:2:
error: #error Inconsistent word size. Checkasm/bitsperlong.h
#error Inconsistent word size. Checkasm/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.hWhich it will if it uses HOSTARCH in
tools/objtool/Makefilewhen 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:
-----------------------------------------------------------------------------
#ifdefined(__powerpc64__)# define __BITS_PER_LONG 64 #else # define __BITS_PER_LONG 32 #endif#ifdef
__SIZEOF_LONG__
#defineBITS_PER_LONG(__CHAR_BIT__*__SIZEOF_LONG__) #else
#defineBITS_PER_LONG__WORDSIZE
#endif#if
BITS_PER_LONG!=__BITS_PER_LONG
#error Inconsistent word size. Checkasm/bitsperlong.h#endif
-----------------------------------------------------------------------------Which I think has no problems, right? The last problem reported ty Stephen now is:
Quoted 4 lines · Stephen Rothwell
That gets me this errors from the
x86_64allmodconfig 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/Buildwill have this:objtool-y += arch/$(ARCH)/
Turned into:
Quoted 8 lines
objtool-y +=
arch/x86/Which will build
tools/objtool/arch/x86/decode.c, that will provide thatarch_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 <[email protected]>
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".
--- tools/objtool/Build | 2 +- tools/objtool/Makefile | 2 +- tools/scripts/Makefile.arch | 32 ++++++++++++++++++++++++++++++++ 3 files changed, 34 insertions(+), 2 deletions(-)
tools/objtool/Build +1 -1
@@ -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
tools/objtool/Makefile +1 -1
@@ -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
tools/scripts/Makefile.arch +32 -0
@@ -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
Em Fri, Jul 22, 2016 at 02:19:20PM -0500, Josh Poimboeuf escreveu:
Quoted 83 lines · Arnaldo Carvalho de Melo
Quoted 82 lines
Em Thu, Jul 21, 2016 at 10:41:18PM -0500, Josh Poimboeuf escreveu:
Quoted 8 lines · Stephen Rothwell
Quoted 2 lines
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.hfiles were merged.So, trying to summarize from the various messages in this thread:
Quoted 10 lines · Stephen Rothwell
It produces these errors (from the
x86_64allmodconfig 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:Quoted 4 lines
/home/sfr/next/next/tools/include/asm-generic/bitsperlong.h:13:2:
error: #error Inconsistent word size. Checkasm/bitsperlong.h
#error Inconsistent word size. Checkasm/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.hWhich it will if it uses HOSTARCH in
tools/objtool/Makefilewhen 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:
-----------------------------------------------------------------------------
#ifdefined(__powerpc64__)# define __BITS_PER_LONG 64 #else # define __BITS_PER_LONG 32 #endif#ifdef
__SIZEOF_LONG__
#defineBITS_PER_LONG(__CHAR_BIT__*__SIZEOF_LONG__) #else
#defineBITS_PER_LONG__WORDSIZE
#endif#if
BITS_PER_LONG!=__BITS_PER_LONG
#error Inconsistent word size. Checkasm/bitsperlong.h#endif
-----------------------------------------------------------------------------Which I think has no problems, right? The last problem reported ty Stephen now is:
Quoted 4 lines · Stephen Rothwell
That gets me this errors from the
x86_64allmodconfig 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/Buildwill have this:objtool-y += arch/$(ARCH)/
Turned into:
objtool-y +=
arch/x86/
Quoted 8 lines
Quoted 6 lines
Which will build
tools/objtool/arch/x86/decode.c, that will provide thatarch_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
Quoted 101 lines
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 <[email protected]>
Subject: [PATCH] tools build: fix objtool build with ARCH=x86_64The 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
Makefilewas doing before; but it's tricky to override environment variables consistently.Instead, take a similar approach used by the Linux top-level
Makefileand introduce a SRCARCHMakefilevariable which evaluates to "x86" when ARCH is either "x86_64" or "x86".Reported-by Stephen Rothwell <[email protected]>Signed-off-by Josh Poimboeuf <[email protected]>--- tools/objtool/Build | 2 +- tools/objtool/Makefile | 2 +- tools/scripts/Makefile.arch | 32 ++++++++++++++++++++++++++++++++ 3 files changed, 34 insertions(+), 2 deletions(-)tools/objtool/Build +1
-1@@ -1,4 +1,4 @@ -objtool-y += arch/$(ARCH)/ +objtool-y += arch/$(SRCARCH)/ objtool-y += builtin-check.o objtool-y += elf.o objtool-y += special.otools/objtool/Makefile +1
-1@@ -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 FORCEtools/scripts/Makefile.arch +32
-0@@ -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
Quoted 99 lines · Arnaldo Carvalho de Melo
Em Fri, Jul 22, 2016 at 02:19:20PM -0500, Josh Poimboeuf escreveu:
Quoted 83 lines · Arnaldo Carvalho de Melo
Quoted 82 lines
Em Thu, Jul 21, 2016 at 10:41:18PM -0500, Josh Poimboeuf escreveu:
Quoted 8 lines · Stephen Rothwell
Quoted 2 lines
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.hfiles were merged.So, trying to summarize from the various messages in this thread:
Quoted 10 lines · Stephen Rothwell
It produces these errors (from the
x86_64allmodconfig 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:Quoted 4 lines
/home/sfr/next/next/tools/include/asm-generic/bitsperlong.h:13:2:
error: #error Inconsistent word size. Checkasm/bitsperlong.h
#error Inconsistent word size. Checkasm/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.hWhich it will if it uses HOSTARCH in
tools/objtool/Makefilewhen 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:
-----------------------------------------------------------------------------
#ifdefined(__powerpc64__)# define __BITS_PER_LONG 64 #else # define __BITS_PER_LONG 32 #endif#ifdef
__SIZEOF_LONG__
#defineBITS_PER_LONG(__CHAR_BIT__*__SIZEOF_LONG__) #else
#defineBITS_PER_LONG__WORDSIZE
#endif#if
BITS_PER_LONG!=__BITS_PER_LONG
#error Inconsistent word size. Checkasm/bitsperlong.h#endif
-----------------------------------------------------------------------------Which I think has no problems, right? The last problem reported ty Stephen now is:
Quoted 4 lines · Stephen Rothwell
That gets me this errors from the
x86_64allmodconfig 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/Buildwill have this:objtool-y += arch/$(ARCH)/
Turned into:
objtool-y +=
arch/x86/Quoted 8 lines
Quoted 6 lines
Which will build
tools/objtool/arch/x86/decode.c, that will provide thatarch_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:
Quoted 6 lines
ifeq ($(ARCH),x86_64)
ARCH := x86
endifBecause, 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.
Signature · 1 line
Josh
Em Fri, Jul 22, 2016 at 02:44:17PM -0500, Josh Poimboeuf escreveu:
Quoted 19 lines · Arnaldo Carvalho de Melo
Quoted 17 lines
Em Fri, Jul 22, 2016 at 02:19:20PM -0500, Josh Poimboeuf escreveu:
Quoted 6 lines · Arnaldo Carvalho de Melo
Quoted 3 lines
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
Quoted 5 lines
Quoted 2 lines
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
Hi Arnaldo,
Quoted 27 lines · On Fri, 22 Jul 2016 16:57:34 -0300 Arnaldo Carvalho de Melo <[email protected]>…
Em Fri, Jul 22, 2016 at 02:44:17PM -0500, Josh Poimboeuf escreveu:
Quoted 19 lines · Arnaldo Carvalho de Melo
Quoted 17 lines
Em Fri, Jul 22, 2016 at 02:19:20PM -0500, Josh Poimboeuf escreveu:
Quoted 6 lines · Arnaldo Carvalho de Melo
Quoted 3 lines
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
endifQuoted 5 lines
Quoted 2 lines
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.
Quoted 6 lines
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 <[email protected]>
Date: Sat, 23 Jul 2016 14:35:40 +1000
Subject: [PATCH] x86: make the vdso2c compiler use the host architecture
headers
--- arch/x86/entry/vdso/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/x86/entry/vdso/Makefile +1 -1
@@ -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 $@
Signature · 6 lines
2.8.1 There may be a more correct way to do this ... -- Cheers, Stephen Rothwell
Andy Lutomirski
Acked-byQuoted 55 lines · Stephen Rothwell
Hi Arnaldo,
Quoted 27 lines · On Fri, 22 Jul 2016 16:57:34 -0300 Arnaldo Carvalho de Melo <[email protected]>…
Em Fri, Jul 22, 2016 at 02:44:17PM -0500, Josh Poimboeuf escreveu:
Quoted 19 lines · Arnaldo Carvalho de Melo
Quoted 17 lines
Em Fri, Jul 22, 2016 at 02:19:20PM -0500, Josh Poimboeuf escreveu:
Quoted 6 lines · Arnaldo Carvalho de Melo
Quoted 3 lines
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
endifQuoted 5 lines
Quoted 2 lines
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.
Quoted 6 lines
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. Checkasm/bitsperlong.h
#error Inconsistent word size. Checkasm/bitsperlong.h
^
Quoted 8 lines
The be clear: this is a ppc64le hosted,
x86_64target cross build.I than added the following patch, and the build finishes successfully.
From: Stephen Rothwell <[email protected]>
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.
Quoted 26 lines
Signed-off-by Stephen Rothwell <[email protected]>--- arch/x86/entry/vdso/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)arch/x86/entry/vdso/Makefile +1
-2@@ -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
Signature · 2 lines
Andy Lutomirski AMA Capital Management, LLC
Em Sat, Jul 23, 2016 at 03:08:45PM +1000, Stephen Rothwell escreveu:
Quoted 9 lines · On Fri, 22 Jul 2016 16:57:34 -0300 Arnaldo Carvalho de Melo <[email protected]>…
Quoted 3 lines
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
Quoted 48 lines
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. Checkasm/bitsperlong.h
#error Inconsistent word size. Checkasm/bitsperlong.h
^The be clear: this is a ppc64le hosted,
x86_64target cross build.I than added the following patch, and the build finishes successfully.
From: Stephen Rothwell <[email protected]>
Date: Sat, 23 Jul 2016 14:35:40 +1000
Subject: [PATCH] x86: make the vdso2c compiler use the host architecture
headersSigned-off-by Stephen Rothwell <[email protected]>--- arch/x86/entry/vdso/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)arch/x86/entry/vdso/Makefile +1
-1@@ -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 $@Signature · 6 lines
2.8.1 There may be a more correct way to do this ... -- Cheers, Stephen Rothwell
tip-bot for Stephen Rothwell
merge bot[tip:perf/core] x86: Make the vdso2c compiler use the host architecture headers
In reply to Stephen Rothwellx86: Make the vdso2c compiler use the host architecture headers
Commit-ID: d51306f1a3bc0e3a7b86d8f2b2dedf34b356d3dd Gitweb: http://git.kernel.org/tip/d51306f1a3bc0e3a7b86d8f2b2dedf34b356d3dd Author: Stephen Rothwell <[email protected]> AuthorDate: Sat, 23 Jul 2016 14:35:40 +1000 Committer: Arnaldo Carvalho de Melo <[email protected]> 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.
--- arch/x86/entry/vdso/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
arch/x86/entry/vdso/Makefile +1 -1
@@ -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 $@
tip-bot for Josh Poimboeuf
merge bot[tip:perf/core] tools build: Fix objtool build with ARCH=x86_64
In reply to Josh Poimboeuftools build: Fix objtool build with ARCH=x86_64
Commit-ID: 60cbdf5d051d4f4db23d267d511ca241d4be7c0d Gitweb: http://git.kernel.org/tip/60cbdf5d051d4f4db23d267d511ca241d4be7c0d Author: Josh Poimboeuf <[email protected]> AuthorDate: Fri, 22 Jul 2016 14:19:20 -0500 Committer: Arnaldo Carvalho de Melo <[email protected]> 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".
--- tools/objtool/Build | 2 +- tools/objtool/Makefile | 2 +- tools/scripts/Makefile.arch | 32 ++++++++++++++++++++++++++++++++ 3 files changed, 34 insertions(+), 2 deletions(-)
tools/objtool/Build +1 -1
@@ -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
tools/objtool/Makefile +1 -1
@@ -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
tools/scripts/Makefile.arch +32 -0
@@ -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-bot for Arnaldo Carvalho de Melo
merge bot[tip:perf/core] objtool: Always use host headers
In reply to Josh Poimboeufobjtool: Always use host headers
Commit-ID: 0cf6eb603b83ea386f26363b5b12e64297822bb1 Gitweb: http://git.kernel.org/tip/0cf6eb603b83ea386f26363b5b12e64297822bb1 Author: Arnaldo Carvalho de Melo <[email protected]> AuthorDate: Fri, 22 Jul 2016 16:28:46 -0300 Committer: Arnaldo Carvalho de Melo <[email protected]> CommitDate: Fri, 22 Jul 2016 16:28:46 -0300
objtool: Always use host headers
Quoted 3 lines
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.
--- tools/objtool/Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
tools/objtool/Makefile +1 -1
@@ -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-bot for Peter Zijlstra
merge bot[tip:perf/core] tools: Simplify BITS_PER_LONG define
In reply to Peter Zijlstratools: Simplify BITS_PER_LONG define
Commit-ID: e81fcd43723d32e9c9dbb8e8d66f147b5b84256b Gitweb: http://git.kernel.org/tip/e81fcd43723d32e9c9dbb8e8d66f147b5b84256b Author: Peter Zijlstra <[email protected]> AuthorDate: Fri, 15 Jul 2016 12:38:18 -0300 Committer: Arnaldo Carvalho de Melo <[email protected]> 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...
--- tools/include/asm-generic/bitsperlong.h | 23 ++--------------------- 1 file changed, 2 insertions(+), 21 deletions(-)
tools/include/asm-generic/bitsperlong.h +2 -21
@@ -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