Linux-Next Archive on lore.kernel.org
 help / color / Atom feed
* linux-next: build failure after merge of the tip tree
@ 2016-03-01  1:29 Stephen Rothwell
  2016-03-01  7:07 ` Ingo Molnar
  0 siblings, 1 reply; 13+ messages in thread
From: Stephen Rothwell @ 2016-03-01  1:29 UTC (permalink / raw)
  To: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra
  Cc: linux-next, linux-kernel, Josh Poimboeuf

Hi all,

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

  DESCEND  objtool
  CC       /home/sfr/next/x86_64_allmodconfig/tools/objtool/builtin-check.o
  CC       /home/sfr/next/x86_64_allmodconfig/tools/objtool/special.o
  CC       /home/sfr/next/x86_64_allmodconfig/tools/objtool/elf.o
  CC       /home/sfr/next/x86_64_allmodconfig/tools/objtool/objtool.o
  MKDIR    /home/sfr/next/x86_64_allmodconfig/tools/objtool/arch/x86/insn/
  CC       /home/sfr/next/x86_64_allmodconfig/tools/objtool/libstring.o
elf.c:22:23: fatal error: sys/types.h: No such file or directory
compilation terminated.
  CC       /home/sfr/next/x86_64_allmodconfig/tools/objtool/exec-cmd.o
  CC       /home/sfr/next/x86_64_allmodconfig/tools/objtool/help.o
builtin-check.c:28:20: fatal error: string.h: No such file or directory
compilation terminated.
objtool.c:28:19: fatal error: stdio.h: No such file or directory
compilation terminated.

and further errors ...

This build is done with a PowerPC hosted cross compiler with no glibc.
I assume that some things here need to be built with HOSTCC?

Presumably caused by commit

  9e54249679b4 ("Merge branch 'core/objtool'")

and the commit series that was merged.

I tried to revert that merge, but it had conflicts, so I just used the
tip tree from next-20160229 for today.

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2016-03-01  1:29 linux-next: build failure after merge of the tip tree Stephen Rothwell
@ 2016-03-01  7:07 ` Ingo Molnar
  2016-03-01  7:28   ` Sedat Dilek
  2016-03-01  9:40   ` Stephen Rothwell
  0 siblings, 2 replies; 13+ messages in thread
From: Ingo Molnar @ 2016-03-01  7:07 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel, Josh Poimboeuf


* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi all,
> 
> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
> 
>   DESCEND  objtool
>   CC       /home/sfr/next/x86_64_allmodconfig/tools/objtool/builtin-check.o
>   CC       /home/sfr/next/x86_64_allmodconfig/tools/objtool/special.o
>   CC       /home/sfr/next/x86_64_allmodconfig/tools/objtool/elf.o
>   CC       /home/sfr/next/x86_64_allmodconfig/tools/objtool/objtool.o
>   MKDIR    /home/sfr/next/x86_64_allmodconfig/tools/objtool/arch/x86/insn/
>   CC       /home/sfr/next/x86_64_allmodconfig/tools/objtool/libstring.o
> elf.c:22:23: fatal error: sys/types.h: No such file or directory
> compilation terminated.
>   CC       /home/sfr/next/x86_64_allmodconfig/tools/objtool/exec-cmd.o
>   CC       /home/sfr/next/x86_64_allmodconfig/tools/objtool/help.o
> builtin-check.c:28:20: fatal error: string.h: No such file or directory
> compilation terminated.
> objtool.c:28:19: fatal error: stdio.h: No such file or directory
> compilation terminated.
> 
> and further errors ...
> 
> This build is done with a PowerPC hosted cross compiler with no glibc.

Ugh, what a rare and weird way to build an x86 kernel, and you made linux-next 
dependent on it?

> I assume that some things here need to be built with HOSTCC?

I suspect that's the culprit. Do you now mandate people to have PowerPC systems as 
a requirement to merge to linux-next? How are people supposed to be able to test 
that rare type of build method which does not matter to 99.99% of our kernel 
testers and users?

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2016-03-01  7:07 ` Ingo Molnar
@ 2016-03-01  7:28   ` Sedat Dilek
  2016-03-01  7:39     ` H. Peter Anvin
  2016-03-01  9:40   ` Stephen Rothwell
  1 sibling, 1 reply; 13+ messages in thread
From: Sedat Dilek @ 2016-03-01  7:28 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, linux-next, LKML, Josh Poimboeuf

On Tue, Mar 1, 2016 at 8:07 AM, Ingo Molnar <mingo@kernel.org> wrote:
>
> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
>> Hi all,
>>
>> After merging the tip tree, today's linux-next build (x86_64 allmodconfig)
>> failed like this:
>>
>>   DESCEND  objtool
>>   CC       /home/sfr/next/x86_64_allmodconfig/tools/objtool/builtin-check.o
>>   CC       /home/sfr/next/x86_64_allmodconfig/tools/objtool/special.o
>>   CC       /home/sfr/next/x86_64_allmodconfig/tools/objtool/elf.o
>>   CC       /home/sfr/next/x86_64_allmodconfig/tools/objtool/objtool.o
>>   MKDIR    /home/sfr/next/x86_64_allmodconfig/tools/objtool/arch/x86/insn/
>>   CC       /home/sfr/next/x86_64_allmodconfig/tools/objtool/libstring.o
>> elf.c:22:23: fatal error: sys/types.h: No such file or directory
>> compilation terminated.
>>   CC       /home/sfr/next/x86_64_allmodconfig/tools/objtool/exec-cmd.o
>>   CC       /home/sfr/next/x86_64_allmodconfig/tools/objtool/help.o
>> builtin-check.c:28:20: fatal error: string.h: No such file or directory
>> compilation terminated.
>> objtool.c:28:19: fatal error: stdio.h: No such file or directory
>> compilation terminated.
>>
>> and further errors ...
>>
>> This build is done with a PowerPC hosted cross compiler with no glibc.
>
> Ugh, what a rare and weird way to build an x86 kernel, and you made linux-next
> dependent on it?
>
>> I assume that some things here need to be built with HOSTCC?
>
> I suspect that's the culprit. Do you now mandate people to have PowerPC systems as
> a requirement to merge to linux-next? How are people supposed to be able to test
> that rare type of build method which does not matter to 99.99% of our kernel
> testers and users?
>

>From my experience in using different $COMPILER you should always pass
CC and HOSTCC in your make-line when building a Linux-kernel or
playing with the Kconfig-system.

When building my llvm-toolchain with make/autoconf I had also to pass
CC and CXX to my configure-line otherwise you got misconfiguration.

[ EXAMPLE: Linux Kconfig-system ]

$ MAKE="make V=1" ; COMPILER="mycompiler" ; MAKE_OPTS="CC=$COMPILER
HOSTCC=$COMPILER"

$ yes "" | $MAKE $MAKE_OPTS oldconfig && $MAKE $MAKE_OPTS
silentoldconfig < /dev/null

- Sedat -

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2016-03-01  7:28   ` Sedat Dilek
@ 2016-03-01  7:39     ` H. Peter Anvin
  2016-03-01  8:41       ` Sedat Dilek
  2016-03-01  9:45       ` Ingo Molnar
  0 siblings, 2 replies; 13+ messages in thread
From: H. Peter Anvin @ 2016-03-01  7:39 UTC (permalink / raw)
  To: sedat.dilek, Ingo Molnar
  Cc: Stephen Rothwell, Thomas Gleixner, Ingo Molnar, Peter Zijlstra,
	linux-next, LKML, Josh Poimboeuf

On February 29, 2016 11:28:22 PM PST, Sedat Dilek <sedat.dilek@gmail.com> wrote:
>On Tue, Mar 1, 2016 at 8:07 AM, Ingo Molnar <mingo@kernel.org> wrote:
>>
>> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>>> Hi all,
>>>
>>> After merging the tip tree, today's linux-next build (x86_64
>allmodconfig)
>>> failed like this:
>>>
>>>   DESCEND  objtool
>>>   CC      
>/home/sfr/next/x86_64_allmodconfig/tools/objtool/builtin-check.o
>>>   CC      
>/home/sfr/next/x86_64_allmodconfig/tools/objtool/special.o
>>>   CC       /home/sfr/next/x86_64_allmodconfig/tools/objtool/elf.o
>>>   CC      
>/home/sfr/next/x86_64_allmodconfig/tools/objtool/objtool.o
>>>   MKDIR   
>/home/sfr/next/x86_64_allmodconfig/tools/objtool/arch/x86/insn/
>>>   CC      
>/home/sfr/next/x86_64_allmodconfig/tools/objtool/libstring.o
>>> elf.c:22:23: fatal error: sys/types.h: No such file or directory
>>> compilation terminated.
>>>   CC      
>/home/sfr/next/x86_64_allmodconfig/tools/objtool/exec-cmd.o
>>>   CC       /home/sfr/next/x86_64_allmodconfig/tools/objtool/help.o
>>> builtin-check.c:28:20: fatal error: string.h: No such file or
>directory
>>> compilation terminated.
>>> objtool.c:28:19: fatal error: stdio.h: No such file or directory
>>> compilation terminated.
>>>
>>> and further errors ...
>>>
>>> This build is done with a PowerPC hosted cross compiler with no
>glibc.
>>
>> Ugh, what a rare and weird way to build an x86 kernel, and you made
>linux-next
>> dependent on it?
>>
>>> I assume that some things here need to be built with HOSTCC?
>>
>> I suspect that's the culprit. Do you now mandate people to have
>PowerPC systems as
>> a requirement to merge to linux-next? How are people supposed to be
>able to test
>> that rare type of build method which does not matter to 99.99% of our
>kernel
>> testers and users?
>>
>
>From my experience in using different $COMPILER you should always pass
>CC and HOSTCC in your make-line when building a Linux-kernel or
>playing with the Kconfig-system.
>
>When building my llvm-toolchain with make/autoconf I had also to pass
>CC and CXX to my configure-line otherwise you got misconfiguration.
>
>[ EXAMPLE: Linux Kconfig-system ]
>
>$ MAKE="make V=1" ; COMPILER="mycompiler" ; MAKE_OPTS="CC=$COMPILER
>HOSTCC=$COMPILER"
>
>$ yes "" | $MAKE $MAKE_OPTS oldconfig && $MAKE $MAKE_OPTS
>silentoldconfig < /dev/null
>
>- Sedat -

That is not the issue here.  The problem is clearly that objtool is a host program and not compiled with host cc.  So it is a good thing to test even though it is weird, because it affects real use cases.

As x86 is far and beyond the most widely used host architecture, cross-compiling x86 is more likely to involve compiler differences than actually using another host, or possibly compiling 32 bits on a system without the 32-bit libc installed, but it should still work.
-- 
Sent from my Android device with K-9 Mail. Please excuse brevity and formatting.

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2016-03-01  7:39     ` H. Peter Anvin
@ 2016-03-01  8:41       ` Sedat Dilek
  2016-03-01  9:45       ` Ingo Molnar
  1 sibling, 0 replies; 13+ messages in thread
From: Sedat Dilek @ 2016-03-01  8:41 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: Ingo Molnar, Stephen Rothwell, Thomas Gleixner, Ingo Molnar,
	Peter Zijlstra, linux-next, LKML, Josh Poimboeuf

On Tue, Mar 1, 2016 at 8:39 AM, H. Peter Anvin <hpa@zytor.com> wrote:
> On February 29, 2016 11:28:22 PM PST, Sedat Dilek <sedat.dilek@gmail.com> wrote:
>>On Tue, Mar 1, 2016 at 8:07 AM, Ingo Molnar <mingo@kernel.org> wrote:
>>>
>>> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>>
>>>> Hi all,
>>>>
>>>> After merging the tip tree, today's linux-next build (x86_64
>>allmodconfig)
>>>> failed like this:
>>>>
>>>>   DESCEND  objtool
>>>>   CC
>>/home/sfr/next/x86_64_allmodconfig/tools/objtool/builtin-check.o
>>>>   CC
>>/home/sfr/next/x86_64_allmodconfig/tools/objtool/special.o
>>>>   CC       /home/sfr/next/x86_64_allmodconfig/tools/objtool/elf.o
>>>>   CC
>>/home/sfr/next/x86_64_allmodconfig/tools/objtool/objtool.o
>>>>   MKDIR
>>/home/sfr/next/x86_64_allmodconfig/tools/objtool/arch/x86/insn/
>>>>   CC
>>/home/sfr/next/x86_64_allmodconfig/tools/objtool/libstring.o
>>>> elf.c:22:23: fatal error: sys/types.h: No such file or directory
>>>> compilation terminated.
>>>>   CC
>>/home/sfr/next/x86_64_allmodconfig/tools/objtool/exec-cmd.o
>>>>   CC       /home/sfr/next/x86_64_allmodconfig/tools/objtool/help.o
>>>> builtin-check.c:28:20: fatal error: string.h: No such file or
>>directory
>>>> compilation terminated.
>>>> objtool.c:28:19: fatal error: stdio.h: No such file or directory
>>>> compilation terminated.
>>>>
>>>> and further errors ...
>>>>
>>>> This build is done with a PowerPC hosted cross compiler with no
>>glibc.
>>>
>>> Ugh, what a rare and weird way to build an x86 kernel, and you made
>>linux-next
>>> dependent on it?
>>>
>>>> I assume that some things here need to be built with HOSTCC?
>>>
>>> I suspect that's the culprit. Do you now mandate people to have
>>PowerPC systems as
>>> a requirement to merge to linux-next? How are people supposed to be
>>able to test
>>> that rare type of build method which does not matter to 99.99% of our
>>kernel
>>> testers and users?
>>>
>>
> >From my experience in using different $COMPILER you should always pass
>>CC and HOSTCC in your make-line when building a Linux-kernel or
>>playing with the Kconfig-system.
>>
>>When building my llvm-toolchain with make/autoconf I had also to pass
>>CC and CXX to my configure-line otherwise you got misconfiguration.
>>
>>[ EXAMPLE: Linux Kconfig-system ]
>>
>>$ MAKE="make V=1" ; COMPILER="mycompiler" ; MAKE_OPTS="CC=$COMPILER
>>HOSTCC=$COMPILER"
>>
>>$ yes "" | $MAKE $MAKE_OPTS oldconfig && $MAKE $MAKE_OPTS
>>silentoldconfig < /dev/null
>>
>>- Sedat -
>
> That is not the issue here.  The problem is clearly that objtool is a host program and not compiled with host cc.  So it is a good thing to test even though it is weird, because it affects real use cases.
>
> As x86 is far and beyond the most widely used host architecture, cross-compiling x86 is more likely to involve compiler differences than actually using another host, or possibly compiling 32 bits on a system without the 32-bit libc installed, but it should still work.
>

Thanks for the clarification.

I talked about my experiences in software building in general.

When this is a "tools/objtool problem" then someone should address
this to "tools/objtool maintainers/folks" or whoever else is
responsible.

- Sedat -

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2016-03-01  7:07 ` Ingo Molnar
  2016-03-01  7:28   ` Sedat Dilek
@ 2016-03-01  9:40   ` Stephen Rothwell
  2016-03-01 21:54     ` [PATCH] objtool: Disable stack validation when CROSS_COMPILE is used Josh Poimboeuf
  1 sibling, 1 reply; 13+ messages in thread
From: Stephen Rothwell @ 2016-03-01  9:40 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: Thomas Gleixner, Ingo Molnar, H. Peter Anvin, Peter Zijlstra,
	linux-next, linux-kernel, Josh Poimboeuf

Hi Ingo,

On Tue, 1 Mar 2016 08:07:50 +0100 Ingo Molnar <mingo@kernel.org> wrote:
>
> > This build is done with a PowerPC hosted cross compiler with no glibc.  
> 
> Ugh, what a rare and weird way to build an x86 kernel, and you made linux-next 
> dependent on it?

It is just the fastest hardware I currently have access to (you remember
who I work for, right? ;-)).  I have always done at least part of the
linux-next building (daily, or overnight) on PowerPC hardware and this
is only the 2nd or third time in over 8 years that it has found an
issue like this.

> > I assume that some things here need to be built with HOSTCC?  
> 
> I suspect that's the culprit.

Good, hopefully it is not too hard to fix.

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: linux-next: build failure after merge of the tip tree
  2016-03-01  7:39     ` H. Peter Anvin
  2016-03-01  8:41       ` Sedat Dilek
@ 2016-03-01  9:45       ` Ingo Molnar
  1 sibling, 0 replies; 13+ messages in thread
From: Ingo Molnar @ 2016-03-01  9:45 UTC (permalink / raw)
  To: H. Peter Anvin
  Cc: sedat.dilek, Stephen Rothwell, Thomas Gleixner, Ingo Molnar,
	Peter Zijlstra, linux-next, LKML, Josh Poimboeuf


* H. Peter Anvin <hpa@zytor.com> wrote:

> That is not the issue here.  The problem is clearly that objtool is a host 
> program and not compiled with host cc.  So it is a good thing to test even 
> though it is weird, because it affects real use cases.

Absolutely, it's a real bug that should be fixed. What is counterproductive is 
that this rare and hard to replicate build modus is now a must-have test for 
linux-next inclusion.

I already cross-build to 20+ weird, rarely used architectures, slowing down the 
linux-next merge integration test immensely and wasting quite a bit of 
electricity. linux-next making it even harder to test for is a step backwards.

Thanks,

	Ingo

^ permalink raw reply	[flat|nested] 13+ messages in thread

* [PATCH] objtool: Disable stack validation when CROSS_COMPILE is used
  2016-03-01  9:40   ` Stephen Rothwell
@ 2016-03-01 21:54     ` Josh Poimboeuf
  2016-03-02  2:27       ` Stephen Rothwell
  0 siblings, 1 reply; 13+ messages in thread
From: Josh Poimboeuf @ 2016-03-01 21:54 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Ingo Molnar, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, linux-next, linux-kernel

On Tue, Mar 01, 2016 at 08:40:01PM +1100, Stephen Rothwell wrote:
> Hi Ingo,
> 
> On Tue, 1 Mar 2016 08:07:50 +0100 Ingo Molnar <mingo@kernel.org> wrote:
> >
> > > This build is done with a PowerPC hosted cross compiler with no glibc.  
> > 
> > Ugh, what a rare and weird way to build an x86 kernel, and you made linux-next 
> > dependent on it?
> 
> It is just the fastest hardware I currently have access to (you remember
> who I work for, right? ;-)).  I have always done at least part of the
> linux-next building (daily, or overnight) on PowerPC hardware and this
> is only the 2nd or third time in over 8 years that it has found an
> issue like this.
> 
> > > I assume that some things here need to be built with HOSTCC?  
> > 
> > I suspect that's the culprit.
> 
> Good, hopefully it is not too hard to fix.

Changing it to use the host compiler would probably be an easy fix, but
that would expose a harder bug related to endianness.

objtool uses the kernel x86 decoder (arch/x86/lib/insn.c) which is
endian-ignorant.  If it tries to analyze reverse endian binaries it gets
confused.  And since CONFIG_STACK_VALIDATION causes objtool to analyze
every .o file in the build, it'll spit out a ton of false warnings.

How about the below workaround patch to disable objtool and warn when
CROSS_COMPILE is used?  If anybody complains about lack of cross-compile
support later, we could try to fix it then.


>From a3c65947011a420743f308b698171c4209105d3f Mon Sep 17 00:00:00 2001
Message-Id: <a3c65947011a420743f308b698171c4209105d3f.1456868910.git.jpoimboe@redhat.com>
From: Josh Poimboeuf <jpoimboe@redhat.com>
Date: Tue, 1 Mar 2016 13:35:51 -0600
Subject: [PATCH] objtool: Disable stack validation when CROSS_COMPILE is used

When building with CONFIG_STACK_VALIDATION on a PowerPC host using an
x86 cross-compiler, Stephen Rothwell saw the following objtool build
errors:

    DESCEND  objtool
    CC       /home/sfr/next/x86_64_allmodconfig/tools/objtool/builtin-check.o
    CC       /home/sfr/next/x86_64_allmodconfig/tools/objtool/special.o
    CC       /home/sfr/next/x86_64_allmodconfig/tools/objtool/elf.o
    CC       /home/sfr/next/x86_64_allmodconfig/tools/objtool/objtool.o
    MKDIR    /home/sfr/next/x86_64_allmodconfig/tools/objtool/arch/x86/insn/
    CC       /home/sfr/next/x86_64_allmodconfig/tools/objtool/libstring.o
  elf.c:22:23: fatal error: sys/types.h: No such file or directory
  compilation terminated.
    CC       /home/sfr/next/x86_64_allmodconfig/tools/objtool/exec-cmd.o
    CC       /home/sfr/next/x86_64_allmodconfig/tools/objtool/help.o
  builtin-check.c:28:20: fatal error: string.h: No such file or directory
  compilation terminated.
  objtool.c:28:19: fatal error: stdio.h: No such file or directory
  compilation terminated.

The problem is that objtool was compiled with the cross compiler instead
of the host compiler.  But even if that were fixed, we'd still have a
problem with endianness.  objtool's x86 decoder (copied from
arch/x86/lib/insn.c) assumes that the endianness of the host and target
are the same.  When analyzing a little-endian x86 binary on a big-endian
host, it will get confused and spit out a bunch of false positive
warnings during the build.

Eventually we may want to add endian awareness to x86 objtool, but
that's generally a rare edge case and it's not clear if anybody would
use it.  For now, when a cross-compiler is used, just disable
CONFIG_STACK_VALIDATION and emit a warning.

Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
---
 Makefile               | 12 +++++++++++-
 scripts/Makefile.build |  4 +++-
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index 8cc926f..b59007c 100644
--- a/Makefile
+++ b/Makefile
@@ -998,8 +998,18 @@ prepare0: archprepare FORCE
 # All the preparing..
 prepare: prepare0 prepare-objtool
 
+
+ifdef CONFIG_STACK_VALIDATION
+  ifeq ($(CROSS_COMPILE),)
+    objtool_target := tools/objtool FORCE
+  else
+    $(warning Stack validation is not supported with cross-compilation.  Disabling CONFIG_STACK_VALIDATION!)
+  endif
+endif
+
 PHONY += prepare-objtool
-prepare-objtool: $(if $(CONFIG_STACK_VALIDATION), tools/objtool FORCE)
+prepare-objtool: $(objtool_target)
+
 
 # Generate some files
 # ---------------------------------------------------------------------------
diff --git a/scripts/Makefile.build b/scripts/Makefile.build
index 130a452..973bb26 100644
--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@ -242,6 +242,7 @@ cmd_record_mcount =						\
 endif
 
 ifdef CONFIG_STACK_VALIDATION
+ifeq ($(CROSS_COMPILE),)
 
 __objtool_obj := $(objtree)/tools/objtool/objtool
 
@@ -260,13 +261,14 @@ objtool_obj = $(if $(patsubst y%,, \
 	$(OBJECT_FILES_NON_STANDARD_$(basetarget).o)$(OBJECT_FILES_NON_STANDARD)n), \
 	$(__objtool_obj))
 
+endif # CROSS_COMPILE
 endif # CONFIG_STACK_VALIDATION
 
 define rule_cc_o_c
 	$(call echo-cmd,checksrc) $(cmd_checksrc)			  \
 	$(call echo-cmd,cc_o_c) $(cmd_cc_o_c);				  \
 	$(cmd_modversions)						  \
-	$(cmd_objtool)						  \
+	$(cmd_objtool)							  \
 	$(call echo-cmd,record_mcount)					  \
 	$(cmd_record_mcount)						  \
 	scripts/basic/fixdep $(depfile) $@ '$(call make-cmd,cc_o_c)' >    \
-- 
2.4.3

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] objtool: Disable stack validation when CROSS_COMPILE is used
  2016-03-01 21:54     ` [PATCH] objtool: Disable stack validation when CROSS_COMPILE is used Josh Poimboeuf
@ 2016-03-02  2:27       ` Stephen Rothwell
  2016-03-02 21:17         ` Josh Poimboeuf
  2016-03-03  7:31         ` Sedat Dilek
  0 siblings, 2 replies; 13+ messages in thread
From: Stephen Rothwell @ 2016-03-02  2:27 UTC (permalink / raw)
  To: Josh Poimboeuf
  Cc: Ingo Molnar, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, linux-next, linux-kernel

Hi Josh,

On Tue, 1 Mar 2016 15:54:51 -0600 Josh Poimboeuf <jpoimboe@redhat.com> wrote:
>
> Changing it to use the host compiler would probably be an easy fix, but
> that would expose a harder bug related to endianness.

Just by luck, my PowerPC host is little endian :-)

> How about the below workaround patch to disable objtool and warn when
> CROSS_COMPILE is used?  If anybody complains about lack of cross-compile
> support later, we could try to fix it then.

This seems reasonable.

> From a3c65947011a420743f308b698171c4209105d3f Mon Sep 17 00:00:00 2001
> Message-Id: <a3c65947011a420743f308b698171c4209105d3f.1456868910.git.jpoimboe@redhat.com>
> From: Josh Poimboeuf <jpoimboe@redhat.com>
> Date: Tue, 1 Mar 2016 13:35:51 -0600
> Subject: [PATCH] objtool: Disable stack validation when CROSS_COMPILE is used

I have applied this to the merge of the tip tree in linux-next today
and it compiles fine for me.  I will continue applying it until
something better comes along or it is applied to the tip tree.

Thanks for that.
-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] objtool: Disable stack validation when CROSS_COMPILE is used
  2016-03-02  2:27       ` Stephen Rothwell
@ 2016-03-02 21:17         ` Josh Poimboeuf
  2016-03-02 22:21           ` Stephen Rothwell
  2016-03-03  7:31         ` Sedat Dilek
  1 sibling, 1 reply; 13+ messages in thread
From: Josh Poimboeuf @ 2016-03-02 21:17 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Ingo Molnar, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, linux-next, linux-kernel

On Wed, Mar 02, 2016 at 01:27:35PM +1100, Stephen Rothwell wrote:
> Hi Josh,
> 
> On Tue, 1 Mar 2016 15:54:51 -0600 Josh Poimboeuf <jpoimboe@redhat.com> wrote:
> >
> > Changing it to use the host compiler would probably be an easy fix, but
> > that would expose a harder bug related to endianness.
> 
> Just by luck, my PowerPC host is little endian :-)

Aha!  In that case, I think I'll take a different approach and try to
add support for CROSS_COMPILE.

We'll need it anyway, later on, when we port objtool to more
architectures.

> > How about the below workaround patch to disable objtool and warn when
> > CROSS_COMPILE is used?  If anybody complains about lack of cross-compile
> > support later, we could try to fix it then.
> 
> This seems reasonable.
> 
> > From a3c65947011a420743f308b698171c4209105d3f Mon Sep 17 00:00:00 2001
> > Message-Id: <a3c65947011a420743f308b698171c4209105d3f.1456868910.git.jpoimboe@redhat.com>
> > From: Josh Poimboeuf <jpoimboe@redhat.com>
> > Date: Tue, 1 Mar 2016 13:35:51 -0600
> > Subject: [PATCH] objtool: Disable stack validation when CROSS_COMPILE is used
> 
> I have applied this to the merge of the tip tree in linux-next today
> and it compiles fine for me.  I will continue applying it until
> something better comes along or it is applied to the tip tree.

Thanks.  I should have the patch(es) soon.  If/when they get merged,
I'll let you know, and then you can drop this one.

-- 
Josh

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] objtool: Disable stack validation when CROSS_COMPILE is used
  2016-03-02 21:17         ` Josh Poimboeuf
@ 2016-03-02 22:21           ` Stephen Rothwell
  0 siblings, 0 replies; 13+ messages in thread
From: Stephen Rothwell @ 2016-03-02 22:21 UTC (permalink / raw)
  To: Josh Poimboeuf
  Cc: Ingo Molnar, Thomas Gleixner, Ingo Molnar, H. Peter Anvin,
	Peter Zijlstra, linux-next, linux-kernel, Michael Ellerman

Hi Josh,

On Wed, 2 Mar 2016 15:17:26 -0600 Josh Poimboeuf <jpoimboe@redhat.com> wrote:
>
> On Wed, Mar 02, 2016 at 01:27:35PM +1100, Stephen Rothwell wrote:
> > 
> > On Tue, 1 Mar 2016 15:54:51 -0600 Josh Poimboeuf <jpoimboe@redhat.com> wrote:  
> > >
> > > Changing it to use the host compiler would probably be an easy fix, but
> > > that would expose a harder bug related to endianness.  
> > 
> > Just by luck, my PowerPC host is little endian :-)  
> 
> Aha!  In that case, I think I'll take a different approach and try to
> add support for CROSS_COMPILE.
> 
> We'll need it anyway, later on, when we port objtool to more
> architectures.

That would be great.  I was discussing this briefly with the powerpc
maintainer and he expressed some interest.

> Thanks.  I should have the patch(es) soon.  If/when they get merged,
> I'll let you know, and then you can drop this one.

OK, I will keep an eye out - I usually notice when stuff get fixed, but
a heads up is always helpful.

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] objtool: Disable stack validation when CROSS_COMPILE is used
  2016-03-02  2:27       ` Stephen Rothwell
  2016-03-02 21:17         ` Josh Poimboeuf
@ 2016-03-03  7:31         ` Sedat Dilek
  2016-03-03  7:57           ` Stephen Rothwell
  1 sibling, 1 reply; 13+ messages in thread
From: Sedat Dilek @ 2016-03-03  7:31 UTC (permalink / raw)
  To: Stephen Rothwell
  Cc: Josh Poimboeuf, Ingo Molnar, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Peter Zijlstra, linux-next, linux-kernel

On 3/2/16, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi Josh,
>
> On Tue, 1 Mar 2016 15:54:51 -0600 Josh Poimboeuf <jpoimboe@redhat.com>
> wrote:
>>
>> Changing it to use the host compiler would probably be an easy fix, but
>> that would expose a harder bug related to endianness.
>
> Just by luck, my PowerPC host is little endian :-)
>
>> How about the below workaround patch to disable objtool and warn when
>> CROSS_COMPILE is used?  If anybody complains about lack of cross-compile
>> support later, we could try to fix it then.
>
> This seems reasonable.
>
>> From a3c65947011a420743f308b698171c4209105d3f Mon Sep 17 00:00:00 2001
>> Message-Id:
>> <a3c65947011a420743f308b698171c4209105d3f.1456868910.git.jpoimboe@redhat.com>
>> From: Josh Poimboeuf <jpoimboe@redhat.com>
>> Date: Tue, 1 Mar 2016 13:35:51 -0600
>> Subject: [PATCH] objtool: Disable stack validation when CROSS_COMPILE is
>> used
>
> I have applied this to the merge of the tip tree in linux-next today
> and it compiles fine for me.  I will continue applying it until
> something better comes along or it is applied to the tip tree.
>

Does Linux next-20160303 has this patch?
On a quick view I could not find it.

- Sedat -

> Thanks for that.
> --
> Cheers,
> Stephen Rothwell
> --
> To unsubscribe from this list: send the line "unsubscribe linux-next" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: [PATCH] objtool: Disable stack validation when CROSS_COMPILE is used
  2016-03-03  7:31         ` Sedat Dilek
@ 2016-03-03  7:57           ` Stephen Rothwell
  0 siblings, 0 replies; 13+ messages in thread
From: Stephen Rothwell @ 2016-03-03  7:57 UTC (permalink / raw)
  To: Sedat Dilek
  Cc: Josh Poimboeuf, Ingo Molnar, Thomas Gleixner, Ingo Molnar,
	H. Peter Anvin, Peter Zijlstra, linux-next, linux-kernel

Hi Sedat,

On Thu, 3 Mar 2016 08:31:57 +0100 Sedat Dilek <sedat.dilek@gmail.com> wrote:
>
> Does Linux next-20160303 has this patch?
> On a quick view I could not find it.

It is applied as part of the merge commit that merges the tip tree, so
there is not a separate commit for it.

-- 
Cheers,
Stephen Rothwell

^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, back to index

Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-03-01  1:29 linux-next: build failure after merge of the tip tree Stephen Rothwell
2016-03-01  7:07 ` Ingo Molnar
2016-03-01  7:28   ` Sedat Dilek
2016-03-01  7:39     ` H. Peter Anvin
2016-03-01  8:41       ` Sedat Dilek
2016-03-01  9:45       ` Ingo Molnar
2016-03-01  9:40   ` Stephen Rothwell
2016-03-01 21:54     ` [PATCH] objtool: Disable stack validation when CROSS_COMPILE is used Josh Poimboeuf
2016-03-02  2:27       ` Stephen Rothwell
2016-03-02 21:17         ` Josh Poimboeuf
2016-03-02 22:21           ` Stephen Rothwell
2016-03-03  7:31         ` Sedat Dilek
2016-03-03  7:57           ` Stephen Rothwell

Linux-Next Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-next/0 linux-next/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-next linux-next/ https://lore.kernel.org/linux-next \
		linux-next@vger.kernel.org
	public-inbox-index linux-next

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-next


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git