lkml.org 
[lkml]   [2019]   [Aug]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
From
SubjectRe: linux-next: build failure after merge of the arm64 tree
Date
Will Deacon <will@kernel.org> writes:
> On Tue, Aug 06, 2019 at 07:34:36PM -0700, Peter Collingbourne wrote:
>> On Tue, Aug 6, 2019 at 4:50 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>> > After merging the arm64 tree, today's linux-next build (powerpc
>> > ppc64_defconfig) was just spinning in make - it executing some scripts,
>> > but it was hard to catch just what.
>> >
>> > Apparently caused by commit
>> >
>> > 5cf896fb6be3 ("arm64: Add support for relocating the kernel with RELR relocations")
>> >
>> > I have not idea why, but reverting the above commit allows to build
>> > to finish.
>>
>> Okay, I can reproduce with:
>
> Likewise.
>
>> That leads me to ask what is special about $(NM) + powerpc? It turns
>> out to be this fragment of arch/powerpc/Makefile:
>>
>> ifdef CONFIG_PPC64
>> new_nm := $(shell if $(NM) --help 2>&1 | grep -- '--synthetic' >
>> /dev/null; then echo y; else echo n; fi)
>>
>> ifeq ($(new_nm),y)
>> NM := $(NM) --synthetic
>> endif
>> endif
>>
>> We're setting NM to something else based on a config option, which I
>> presume sets up some sort of circular dependency that confuses
>> Kconfig. Removing this fragment of the makefile (or appending
>> --synthetic unconditionally) also makes the problem go away.
>
> Yes, I think you're right. The lack of something like KBUILD_NMFLAGS means
> that architectures are forced to override NM entirely if they want to pass
> any specific options. Making that conditional on a Kconfig option appears
> to send the entire thing recursive.
>
>> So I guess we have a couple of possible quick fixes (assuming that the
>> Kconfig issue can't be solved somehow): either stop passing --synthetic on
>> powerpc and lose a couple of symbols in 64-bit kernels, or start passing
>> it unconditionally on powerpc (it doesn't seem to make a difference to the
>> nm output on a ppc64_defconfig kernel with CONFIG_PPC64=n). I'm cc'ing the
>> powerpc maintainers for their opinion on what to do. While this is being
>> resolved we should probably back out my patch from -next.
>
> Although Alpha, Itanic and PowerPC all override NM, only PowerPC does it
> conditionally so I agree with you that passing '--synthetic' unconditionally
> would resolve the problem and is certainly my preferred approach if mpe is
> ok with it.

I'd rather we keep passing --synthetic, otherwise there's the potential
that symbols go missing that were previously visible.

I think we can keep the new_nm check, but drop the dependency on
CONFIG_PPC64, and that will fix it. Worst case is we start passing
--synthetic on ppc32, but that's probably not a problem.

This seems to fix it for me, and 32-bit builds fine.

Do you want me to send a proper patch for this, or do you want to squash
it into the original series?

diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile
index c345b79414a9..403f7e193833 100644
--- a/arch/powerpc/Makefile
+++ b/arch/powerpc/Makefile
@@ -39,13 +39,11 @@ endif
uname := $(shell uname -m)
KBUILD_DEFCONFIG := $(if $(filter ppc%,$(uname)),$(uname),ppc64)_defconfig

-ifdef CONFIG_PPC64
new_nm := $(shell if $(NM) --help 2>&1 | grep -- '--synthetic' > /dev/null; then echo y; else echo n; fi)

ifeq ($(new_nm),y)
NM := $(NM) --synthetic
endif
-endif

# BITS is used as extension for files which are available in a 32 bit
# and a 64 bit version to simplify shared Makefiles.

cheers

\
 
 \ /
  Last update: 2019-08-16 06:53    [W:0.076 / U:0.156 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site