Message-ID: <20190807152506.m2mzzjtb7kzjoiia@willie-the-truck>
Date:   Wed, 7 Aug 2019 16:25:06 +0100
From:   Will Deacon <will@...nel.org>
To:     Masahiro Yamada <yamada.masahiro@...ionext.com>
Cc:     Peter Collingbourne <pcc@...gle.com>,
        Stephen Rothwell <sfr@...b.auug.org.au>,
        Catalin Marinas <catalin.marinas@....com>,
        Linux Next Mailing List <linux-next@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Benjamin Herrenschmidt <benh@...nel.crashing.org>,
        Paul Mackerras <paulus@...ba.org>,
        Michael Ellerman <mpe@...erman.id.au>
Subject: Re: linux-next: build failure after merge of the arm64 tree

Hello Masahiro,

On Wed, Aug 07, 2019 at 11:43:02PM +0900, Masahiro Yamada wrote:
> On Wed, Aug 7, 2019 at 8:46 PM Will Deacon <will@...nel.org> wrote:
> > On Tue, Aug 06, 2019 at 07:34:36PM -0700, Peter Collingbourne wrote:
> > > 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.
> 
> Exactly. This makes a circular dependency.
> Kconfig determines the environment variable 'NM' has been changed,
> and re-runs.
> 
> > 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.
> 
> Adding KBUILD_NMFLAGS is probably the right thing to do.
> (Is there somebody who wants to volunteer for this?)

I don't think so ;) We don't do this for many other tools, and there's only
this one case that really seems to require it.

> But, for this particular case, I vote for
> the entire removal of --synthetic.
> 
> This dates back to 2004, and the commit message
> did not clearly explain why it was needed.
> 
> The PowerPC maintainers should re-evaluate
> whether or not this flag is necessary.
> 
> ppc32 is working without --synthetic,
> so probably ppc64 would be ...

Again, this is up to the PPC maintainers.

> > diff --git a/init/Kconfig b/init/Kconfig
> > index d96127ebc44e..a38027a06b79 100644
> > --- a/init/Kconfig
> > +++ b/init/Kconfig
> > @@ -31,7 +31,7 @@ config CC_HAS_ASM_GOTO
> >         def_bool $(success,$(srctree)/scripts/gcc-goto.sh $(CC))
> >
> >  config TOOLS_SUPPORT_RELR
> > -       def_bool $(success,env "CC=$(CC)" "LD=$(LD)" "NM=$(NM)" "OBJCOPY=$(OBJCOPY)" $(srctree)/scripts/tools-support-relr.sh)
> > +       def_bool $(success,env "CC=$(CC)" "LD=$(LD)" "NM=$(CROSS_COMPILE)nm" "OBJCOPY=$(OBJCOPY)" $(srctree)/scripts/tools-support-relr.sh)
> >
> >  config CC_HAS_WARN_MAYBE_UNINITIALIZED
> >         def_bool $(cc-option,-Wmaybe-uninitialized)
> 
> Maybe,
> 
> def_bool $(success,env "CC=$(CC)" "LD=$(LD)" "OBJCOPY=$(OBJCOPY)"
> $(srctree)/scripts/tools-support-relr.sh)
> 
> will work.

Oh yes, I prefer that. I've included the updated patch below, and I'll
put it into -next shortly so that we resolve the build breakage. Hopefully
we'll have a better fix once the ozlabs folks wake up.

> Or more simply
> 
> def_bool $(success,$(srctree)/scripts/tools-support-relr.sh)
> 
> CC, LD, OBJCOPY, NM are environment variables,
> so I think tools-support-relr.sh can directly use them.

Maybe, but the other scripts invoked here tend to pass $(CC) through as
an argument, and that helps with your observation below...:

> However, this bypasses the detection of environment variable changes.
> If a user passes NM= from the command line, Kconfig will no longer
> notice the change of NM.

... but since my proposal also breaks this, then I think your idea of just
dropping $NM for now is best.

Will

--->8

>From 71c67a31f09fa8fdd1495dffd96a5f0d4cef2ede Mon Sep 17 00:00:00 2001
From: Will Deacon <will@...nel.org>
Date: Wed, 7 Aug 2019 12:48:33 +0100
Subject: [PATCH] init/Kconfig: Fix infinite Kconfig recursion on PPC

Commit 5cf896fb6be3 ("arm64: Add support for relocating the kernel with
RELR relocations") introduced CONFIG_TOOLS_SUPPORT_RELR, which checks
for RELR support in the toolchain as part of the kernel configuration.
During this procedure, "$(NM)" is invoked to see if it supports the new
relocation format, however PowerPC conditionally overrides this variable
in the architecture Makefile in order to pass '--synthetic' when
targetting PPC64.

This conditional override causes Kconfig to recurse forever, since
CONFIG_TOOLS_SUPPORT_RELR cannot be determined without $(NM) being
defined, but that in turn depends on CONFIG_PPC64:

  $ make ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu-
  scripts/kconfig/conf  --syncconfig Kconfig
  scripts/kconfig/conf  --syncconfig Kconfig
  scripts/kconfig/conf  --syncconfig Kconfig
  [...]

In this particular case, it looks like PowerPC may be able to pass
'--synthetic' unconditionally to nm or even drop it altogether. While
that is being resolved, let's just bodge the RELR check by picking up
$(NM) directly from the environment in whatever state it happens to be
in.

Cc: Peter Collingbourne <pcc@...gle.com>
Reported-by: Stephen Rothwell <sfr@...b.auug.org.au>
Suggested-by: Masahiro Yamada <yamada.masahiro@...ionext.com>
Signed-off-by: Will Deacon <will@...nel.org>
---
 init/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/init/Kconfig b/init/Kconfig
index d96127ebc44e..8b4596edda4e 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -31,7 +31,7 @@ config CC_HAS_ASM_GOTO
 	def_bool $(success,$(srctree)/scripts/gcc-goto.sh $(CC))
 
 config TOOLS_SUPPORT_RELR
-	def_bool $(success,env "CC=$(CC)" "LD=$(LD)" "NM=$(NM)" "OBJCOPY=$(OBJCOPY)" $(srctree)/scripts/tools-support-relr.sh)
+	def_bool $(success,env "CC=$(CC)" "LD=$(LD)" "OBJCOPY=$(OBJCOPY)" $(srctree)/scripts/tools-support-relr.sh)
 
 config CC_HAS_WARN_MAYBE_UNINITIALIZED
 	def_bool $(cc-option,-Wmaybe-uninitialized)
-- 
2.17.1

Powered by blists - more mailing lists