Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree
From: Arnaldo Carvalho de Melo <acme@kernel.org>
Date: 2016-07-22 14:37:47
Also in:
lkml
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:quoted
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]$