Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1443984 > unrolled thread
| Started by | Stephen Rothwell <sfr@canb.auug.org.au> |
|---|---|
| First post | 2016-07-15 09:10 +0200 |
| Last post | 2016-07-16 22:50 +0200 |
| Articles | 20 on this page of 43 — 11 participants |
Back to article view | Back to linux.kernel
linux-next: build failure after merge of the luto-misc tree Stephen Rothwell <sfr@canb.auug.org.au> - 2016-07-15 09:10 +0200
Re: linux-next: build failure after merge of the luto-misc tree Peter Zijlstra <peterz@infradead.org> - 2016-07-15 09:30 +0200
Re: linux-next: build failure after merge of the luto-misc tree Peter Zijlstra <peterz@infradead.org> - 2016-07-15 09:40 +0200
Re: linux-next: build failure after merge of the luto-misc tree Arnaldo Carvalho de Melo <acme@redhat.com> - 2016-07-15 17:10 +0200
Re: linux-next: build failure after merge of the luto-misc tree Arnaldo Carvalho de Melo <acme@redhat.com> - 2016-07-15 17:30 +0200
Re: linux-next: build failure after merge of the luto-misc tree Peter Zijlstra <peterz@infradead.org> - 2016-07-15 17:30 +0200
Re: linux-next: build failure after merge of the luto-misc tree Arnaldo Carvalho de Melo <acme@redhat.com> - 2016-07-15 18:00 +0200
Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree Peter Zijlstra <peterz@infradead.org> - 2016-07-15 17:50 +0200
Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree Arnaldo Carvalho de Melo <acme@redhat.com> - 2016-07-15 18:30 +0200
Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree "H. Peter Anvin" <hpa@zytor.com> - 2016-07-15 22:30 +0200
[PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree Arnaldo Carvalho de Melo <acme@redhat.com> - 2016-07-15 17:50 +0200
Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree Stephen Rothwell <sfr@canb.auug.org.au> - 2016-07-18 07:20 +0200
Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree Andy Lutomirski <luto@amacapital.net> - 2016-07-18 22:10 +0200
Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree Arnaldo Carvalho de Melo <acme@kernel.org> - 2016-07-18 22:40 +0200
Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree Stephen Rothwell <sfr@canb.auug.org.au> - 2016-07-19 00:30 +0200
Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree Arnaldo Carvalho de Melo <acme@kernel.org> - 2016-07-19 01:50 +0200
Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree Stephen Rothwell <sfr@canb.auug.org.au> - 2016-07-19 02:30 +0200
Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree Arnaldo Carvalho de Melo <acme@kernel.org> - 2016-07-19 02:40 +0200
Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree Stephen Rothwell <sfr@canb.auug.org.au> - 2016-07-19 05:30 +0200
Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree Arnaldo Carvalho de Melo <acme@kernel.org> - 2016-07-19 15:00 +0200
Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree Arnaldo Carvalho de Melo <acme@kernel.org> - 2016-07-19 19:50 +0200
Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree Stephen Rothwell <sfr@canb.auug.org.au> - 2016-07-20 01:30 +0200
Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree Stephen Rothwell <sfr@canb.auug.org.au> - 2016-07-20 02:00 +0200
Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree Andy Lutomirski <luto@amacapital.net> - 2016-07-20 05:00 +0200
Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree Arnaldo Carvalho de Melo <acme@redhat.com> - 2016-07-20 05:10 +0200
Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree Stephen Rothwell <sfr@canb.auug.org.au> - 2016-07-20 05:20 +0200
Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree Arnaldo Carvalho de Melo <acme@kernel.org> - 2016-07-20 05:00 +0200
Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree Stephen Rothwell <sfr@canb.auug.org.au> - 2016-07-21 01:40 +0200
Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree Arnaldo Carvalho de Melo <acme@kernel.org> - 2016-07-21 15:20 +0200
Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree Stephen Rothwell <sfr@canb.auug.org.au> - 2016-07-22 01:30 +0200
Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree Josh Poimboeuf <jpoimboe@redhat.com> - 2016-07-22 05:50 +0200
Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree Arnaldo Carvalho de Melo <acme@kernel.org> - 2016-07-22 16:40 +0200
Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree Josh Poimboeuf <jpoimboe@redhat.com> - 2016-07-22 21:20 +0200
Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree Arnaldo Carvalho de Melo <acme@kernel.org> - 2016-07-22 21:40 +0200
Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree Josh Poimboeuf <jpoimboe@redhat.com> - 2016-07-22 21:50 +0200
Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree Arnaldo Carvalho de Melo <acme@kernel.org> - 2016-07-22 22:00 +0200
Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree Stephen Rothwell <sfr@canb.auug.org.au> - 2016-07-23 07:10 +0200
Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree Andy Lutomirski <luto@amacapital.net> - 2016-07-24 20:50 +0200
Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree Arnaldo Carvalho de Melo <acme@kernel.org> - 2016-07-25 15:00 +0200
[tip:perf/core] x86: Make the vdso2c compiler use the host architecture headers tip-bot for Stephen Rothwell <tipbot@zytor.com> - 2016-07-25 20:20 +0200
[tip:perf/core] tools build: Fix objtool build with ARCH=x86_64 tip-bot for Josh Poimboeuf <tipbot@zytor.com> - 2016-07-25 20:20 +0200
[tip:perf/core] objtool: Always use host headers tip-bot for Arnaldo Carvalho de Melo <tipbot@zytor.com> - 2016-07-25 20:20 +0200
[tip:perf/core] tools: Simplify BITS_PER_LONG define tip-bot for Peter Zijlstra <tipbot@zytor.com> - 2016-07-16 22:50 +0200
Page 2 of 3 — ← Prev page 1 [2] 3 Next page →
| From | Arnaldo Carvalho de Melo <acme@kernel.org> |
|---|---|
| Date | 2016-07-19 19:50 +0200 |
| Subject | Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree |
| Message-ID | <rWHjz-6Zz-1@gated-at.bofh.it> |
| In reply to | #1446428 |
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
[toc] | [prev] | [next] | [standalone]
| From | Stephen Rothwell <sfr@canb.auug.org.au> |
|---|---|
| Date | 2016-07-20 01:30 +0200 |
| Subject | Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree |
| Message-ID | <rWMCC-1Wj-29@gated-at.bofh.it> |
| In reply to | #1446612 |
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
[toc] | [prev] | [next] | [standalone]
| From | Stephen Rothwell <sfr@canb.auug.org.au> |
|---|---|
| Date | 2016-07-20 02:00 +0200 |
| Subject | Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree |
| Message-ID | <rWN5D-26r-9@gated-at.bofh.it> |
| In reply to | #1446794 |
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
[toc] | [prev] | [next] | [standalone]
| From | Andy Lutomirski <luto@amacapital.net> |
|---|---|
| Date | 2016-07-20 05:00 +0200 |
| Subject | Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree |
| Message-ID | <rWPTP-41h-7@gated-at.bofh.it> |
| In reply to | #1446808 |
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
[toc] | [prev] | [next] | [standalone]
| From | Arnaldo Carvalho de Melo <acme@redhat.com> |
|---|---|
| Date | 2016-07-20 05:10 +0200 |
| Subject | Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree |
| Message-ID | <rWQ3v-4jO-5@gated-at.bofh.it> |
| In reply to | #1446903 |
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
[toc] | [prev] | [next] | [standalone]
| From | Stephen Rothwell <sfr@canb.auug.org.au> |
|---|---|
| Date | 2016-07-20 05:20 +0200 |
| Subject | Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree |
| Message-ID | <rWQdb-4mO-3@gated-at.bofh.it> |
| In reply to | #1446913 |
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
[toc] | [prev] | [next] | [standalone]
| From | Arnaldo Carvalho de Melo <acme@kernel.org> |
|---|---|
| Date | 2016-07-20 05:00 +0200 |
| Subject | Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree |
| Message-ID | <rWPTP-41h-9@gated-at.bofh.it> |
| In reply to | #1446808 |
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
[toc] | [prev] | [next] | [standalone]
| From | Stephen Rothwell <sfr@canb.auug.org.au> |
|---|---|
| Date | 2016-07-21 01:40 +0200 |
| Subject | Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree |
| Message-ID | <rX9fP-7YC-9@gated-at.bofh.it> |
| In reply to | #1446908 |
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
[toc] | [prev] | [next] | [standalone]
| From | Arnaldo Carvalho de Melo <acme@kernel.org> |
|---|---|
| Date | 2016-07-21 15:20 +0200 |
| Subject | Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree |
| Message-ID | <rXm3o-7UG-11@gated-at.bofh.it> |
| In reply to | #1447540 |
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)
[toc] | [prev] | [next] | [standalone]
| From | Stephen Rothwell <sfr@canb.auug.org.au> |
|---|---|
| Date | 2016-07-22 01:30 +0200 |
| Subject | Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree |
| Message-ID | <rXvzI-5X0-11@gated-at.bofh.it> |
| In reply to | #1447867 |
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
[toc] | [prev] | [next] | [standalone]
| From | Josh Poimboeuf <jpoimboe@redhat.com> |
|---|---|
| Date | 2016-07-22 05:50 +0200 |
| Subject | Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree |
| Message-ID | <rXzDj-hE-11@gated-at.bofh.it> |
| In reply to | #1448250 |
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
[toc] | [prev] | [next] | [standalone]
| From | Arnaldo Carvalho de Melo <acme@kernel.org> |
|---|---|
| Date | 2016-07-22 16:40 +0200 |
| Subject | Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree |
| Message-ID | <rXJMl-72c-5@gated-at.bofh.it> |
| In reply to | #1448364 |
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]$
[toc] | [prev] | [next] | [standalone]
| From | Josh Poimboeuf <jpoimboe@redhat.com> |
|---|---|
| Date | 2016-07-22 21:20 +0200 |
| Subject | Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree |
| Message-ID | <rXO9j-1uW-1@gated-at.bofh.it> |
| In reply to | #1448617 |
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
[toc] | [prev] | [next] | [standalone]
| From | Arnaldo Carvalho de Melo <acme@kernel.org> |
|---|---|
| Date | 2016-07-22 21:40 +0200 |
| Subject | Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree |
| Message-ID | <rXOsG-1Br-19@gated-at.bofh.it> |
| In reply to | #1448728 |
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
[toc] | [prev] | [next] | [standalone]
| From | Josh Poimboeuf <jpoimboe@redhat.com> |
|---|---|
| Date | 2016-07-22 21:50 +0200 |
| Subject | Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree |
| Message-ID | <rXOCm-1EM-15@gated-at.bofh.it> |
| In reply to | #1448736 |
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
[toc] | [prev] | [next] | [standalone]
| From | Arnaldo Carvalho de Melo <acme@kernel.org> |
|---|---|
| Date | 2016-07-22 22:00 +0200 |
| Subject | Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree |
| Message-ID | <rXOM2-1Io-13@gated-at.bofh.it> |
| In reply to | #1448740 |
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
[toc] | [prev] | [next] | [standalone]
| From | Stephen Rothwell <sfr@canb.auug.org.au> |
|---|---|
| Date | 2016-07-23 07:10 +0200 |
| Subject | Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree |
| Message-ID | <rXXmh-7eH-1@gated-at.bofh.it> |
| In reply to | #1448743 |
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
[toc] | [prev] | [next] | [standalone]
| From | Andy Lutomirski <luto@amacapital.net> |
|---|---|
| Date | 2016-07-24 20:50 +0200 |
| Subject | Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree |
| Message-ID | <rYwDn-2Sx-1@gated-at.bofh.it> |
| In reply to | #1448874 |
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
[toc] | [prev] | [next] | [standalone]
| From | Arnaldo Carvalho de Melo <acme@kernel.org> |
|---|---|
| Date | 2016-07-25 15:00 +0200 |
| Subject | Re: [PATCH/RFC] Re: linux-next: build failure after merge of the luto-misc tree |
| Message-ID | <rYNEd-4FI-3@gated-at.bofh.it> |
| In reply to | #1448874 |
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
[toc] | [prev] | [next] | [standalone]
| From | tip-bot for Stephen Rothwell <tipbot@zytor.com> |
|---|---|
| Date | 2016-07-25 20:20 +0200 |
| Subject | [tip:perf/core] x86: Make the vdso2c compiler use the host architecture headers |
| Message-ID | <rYSDV-7Sa-41@gated-at.bofh.it> |
| In reply to | #1448874 |
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 $@
[toc] | [prev] | [next] | [standalone]
Page 2 of 3 — ← Prev page 1 [2] 3 Next page →
Back to top | Article view | linux.kernel
csiph-web