From: Peter Collingbourne <pcc@google.com>
To: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
Linux Next Mailing List <linux-next@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Masahiro Yamada <yamada.masahiro@socionext.com>,
benh@kernel.crashing.org, paulus@samba.org, mpe@ellerman.id.au
Subject: Re: linux-next: build failure after merge of the arm64 tree
Date: Tue, 6 Aug 2019 19:34:36 -0700 [thread overview]
Message-ID: <CAMn1gO6P_VfDRjGZb67ZS4Kh0wjTEQi0cbOkmibTokHQOgP7qw@mail.gmail.com> (raw)
In-Reply-To: <20190807095022.0314e2fc@canb.auug.org.au>
On Tue, Aug 6, 2019 at 4:50 PM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> 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:
$ make ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu- defconfig
*** Default configuration is based on 'ppc64_defconfig'
#
# No change to .config
#
$ make ARCH=powerpc CROSS_COMPILE=powerpc-linux-gnu- -j72
scripts/kconfig/conf --syncconfig Kconfig
scripts/kconfig/conf --syncconfig Kconfig
scripts/kconfig/conf --syncconfig Kconfig
[...]
And confirmed that backing out my patch fixes it.
The problem seems to come from the use of $(NM) in the Kconfig file.
If I apply this diff:
diff --git a/init/Kconfig b/init/Kconfig
index d96127ebc44e0..177a95b323230 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,$(NM))
config CC_HAS_WARN_MAYBE_UNINITIALIZED
def_bool $(cc-option,-Wmaybe-uninitialized)
I still see the hang. Replacing $(NM) with something else makes it go away.
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.
We should at least able to remove the test for a new-enough binutils.
According to changes.rst we require binutils 2.21 which was released
in 2011, and support for --synthetic was added to binutils in 2004:
https://github.com/bminor/binutils-gdb/commit/0873df2aec48685715d2c5041c1f6f4ed43976c1
But why are we passing --synthetic at all on ppc64? This behaviour
seems to come from this commit from 2004:
https://github.com/mpe/linux-fullhistory/commit/0e32679a4ea48a634d94e97355d47512ef14d71f
which states: "On new toolchains we need to use nm --synthetic or we
miss code symbols."
But I only see a couple of missing symbols if I compare the output of
nm with and without --synthetic on a powerpc64 kernel:
$ diff -u <(powerpc-linux-gnu-nm --synthetic vmlinux)
<(powerpc-linux-gnu-nm vmlinux)
--- /dev/fd/63 2019-08-06 18:48:56.127020621 -0700
+++ /dev/fd/62 2019-08-06 18:48:56.131020636 -0700
@@ -74840,7 +74840,6 @@
c000000001901b10 D LZ4_decompress_fast
c0000000007819a0 T .LZ4_decompress_fast_continue
c000000001901b70 D LZ4_decompress_fast_continue
-c0000000007811e0 t .LZ4_decompress_fast_extDict
c000000001901b40 d LZ4_decompress_fast_extDict
c000000000781960 T .LZ4_decompress_fast_usingDict
c000000001901b58 D LZ4_decompress_fast_usingDict
@@ -74856,7 +74855,6 @@
c000000001901bd0 D LZ4_decompress_safe_usingDict
c0000000007822b0 T .LZ4_decompress_safe_withPrefix64k
c000000001901b88 D LZ4_decompress_safe_withPrefix64k
-c000000000780c60 t .LZ4_decompress_safe_withSmallPrefix
c000000001901b28 d LZ4_decompress_safe_withSmallPrefix
c00000000077fbe0 T .LZ4_setStreamDecode
c000000001901ac8 D LZ4_setStreamDecode
I guess the problem was worse back in 2004. It almost certainly didn't
involve these particular symbols because they were added in commit
2209fda323e2fd2a2d0885595fd5097717f8d2aa from 2018. 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.
Peter
next prev parent reply other threads:[~2019-08-07 2:34 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-08-06 23:50 linux-next: build failure after merge of the arm64 tree Stephen Rothwell
2019-08-07 2:34 ` Peter Collingbourne [this message]
2019-08-07 11:46 ` Will Deacon
2019-08-07 14:43 ` Masahiro Yamada
2019-08-07 15:25 ` Will Deacon
2019-08-07 16:33 ` Peter Collingbourne
2019-08-07 23:43 ` Stephen Rothwell
2019-08-16 4:52 ` Michael Ellerman
2019-08-16 17:27 ` Will Deacon
2019-08-20 7:27 ` Michael Ellerman
-- strict thread matches above, loose matches on Subject: below --
2022-11-21 23:41 Stephen Rothwell
2022-11-22 4:17 ` Jiucheng Xu
2022-11-22 4:52 ` Stephen Rothwell
2022-11-15 22:04 Stephen Rothwell
2022-11-15 23:52 ` Besar Wicaksono
2022-11-16 10:49 ` Suzuki K Poulose
2015-03-27 0:15 Stephen Rothwell
2012-09-17 1:24 Stephen Rothwell
2012-09-17 8:41 ` Catalin Marinas
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAMn1gO6P_VfDRjGZb67ZS4Kh0wjTEQi0cbOkmibTokHQOgP7qw@mail.gmail.com \
--to=pcc@google.com \
--cc=benh@kernel.crashing.org \
--cc=catalin.marinas@arm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=mpe@ellerman.id.au \
--cc=paulus@samba.org \
--cc=sfr@canb.auug.org.au \
--cc=will@kernel.org \
--cc=yamada.masahiro@socionext.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).