From: Nathan Chancellor <nathan@kernel.org>
To: Will Deacon <will@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
linux-arm-kernel@lists.infradead.org, catalin.marinas@arm.com,
keescook@chromium.org, ardb@kernel.org
Subject: Re: allmodconfig builds failing to link on arm64
Date: Fri, 8 Apr 2022 10:17:19 -0700 [thread overview]
Message-ID: <YlBuH2ScVeRO93AG@dev-arch.thelio-3990X> (raw)
In-Reply-To: <20220408161344.GA28108@willie-the-truck>
On Fri, Apr 08, 2022 at 05:13:44PM +0100, Will Deacon wrote:
> On Fri, Apr 08, 2022 at 04:06:39PM +0100, Mark Rutland wrote:
> > On Fri, Apr 08, 2022 at 03:45:42PM +0100, Mark Rutland wrote:
> > > On Fri, Apr 08, 2022 at 12:54:07PM +0100, Will Deacon wrote:
> > > > Since -rc1 (although I haven't tried bisecting the merge window), I'm
> > > > not able to link allmodconfig for arm64:
> > > >
> > > > aarch64-linux-gnu-ld: .init.data has both ordered [`__patchable_function_entries' in init/main.o] and unordered [`.init_array.1' in virt/lib/irqbypass.o] sections
> > > > aarch64-linux-gnu-ld: final link failed: bad value
> > > > make: *** [Makefile:1158: vmlinux] Error 1
> > > >
> > > > I'm using an Android clang based on 12.0.6 and LD claims to be
> > > > 2.33.1.20191209.
> > >
> > > I can reproduce that when using the llvm.org 12.0.0 binaries along with the
> > > kernel.org crosstool 9.2.0 binaries (binutils 2.32) to build v5.18-rc1
> > > allmodconfig.
> > >
> > > I see the failure with (at least) the following combinations that I tested:
> > >
> > > * LLVM 11.0.0 && binutils 2.34 (kernel.org 8.4.0 binaries)
> > > * LLVM 12.0.0 && binutils 2.30 (kernel.org 8.1.0 binaries)
> > > * LLVM 12.0.0 && binutils 2.32 (kernel.org 9.2.0 binaries)
> > > * LLVM 12.0.0 && binutils 2.34 (kernel.org 8.4.0/9.3.0 binaries)
> > > * LLVM 13.0.0 && binutils 2.34 (kernel.org 8.4.0 binaries)
> > > * LLVM 14.0.0 && binutils 2.34 (kernel.org 8.4.0 binaries)
> > >
> > > I *DO NOT* see the failure with the following combinations:
> > >
> > > * LLVM 12.0.0 && binutils 2.36.1 (kernel.org 10.3.0/11.1.0 binaries)
> > > * LLVM 13.0.0 && binutils 2.36.1 (kernel.org 10.3.0/11.1.0 binaries)
> > > * LLVM 14.0.0 && binutils 2.36.1 (kernel.org 10.3.0/11.1.0 binaries)
> > >
> > > So clearly something changed on the binutils side between 2.34 and
> > > 2.36.1, but I don't know whether either behaviour is incorrect, or
> > > whether LLVM implicitly depends upon a newer binutils version.
> > >
> > > I don't know why this suddenly became a problem in v5.18-rc1; I'll have
> > > a look.
> >
> > I also see this with earlier kernel versions, including:
> >
> > * v5.15 allmodconfig, LLVM 12.0.0, binutils 2.30 (kernel.org 8.1.0 binaries)
> > * v5.16 allmodconfig, LLVM 12.0.0, binutils 2.30 (kernel.org 8.1.0 binaries)
> > * v5.17 allmodconfig, LLVM 12.0.0, binutils 2.30 (kernel.org 8.1.0 binaries)
> >
> > ... so it doesn't look like this is a (recent) regression.
>
> Damn, sorry for the mis-diagnosis then. I only just started seeing it, but
> thinking about it I _usually_ build with LLVM=1 which probably rules out
> binutils entirely. For some reason, I ended up in the mixed case today
> and ran into this.
>
> In any case, it would be good to get it resolved and I'm happy to test out
> any fixes.
I came up with the following diff. I could make the second "depends on"
line a little more readable by splitting it out to two different symbols
such as GCC_SUPPORTS_DYNAMIC_FTRACE_WITH_REGS and
CLANG_SUPPORTS_DYNAMIC_FTRACE_WITH_REGS, which lines up with Linus'
preference here:
https://lore.kernel.org/r/CAHk-=whzW56xChey=k+9KeK_NFxWLfZrt5UWvVjTxYbHLP1Nwg@mail.gmail.com/
That decision is ultimately up to you all though! I can formally send
this along if it looks okay or rework it here depending on feedback.
Cheers,
Nathan
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 57c4c995965f..b2a10846608a 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -175,8 +175,6 @@ config ARM64
select HAVE_DEBUG_KMEMLEAK
select HAVE_DMA_CONTIGUOUS
select HAVE_DYNAMIC_FTRACE
- select HAVE_DYNAMIC_FTRACE_WITH_REGS \
- if $(cc-option,-fpatchable-function-entry=2)
select FTRACE_MCOUNT_USE_PATCHABLE_FUNCTION_ENTRY \
if DYNAMIC_FTRACE_WITH_REGS
select HAVE_EFFICIENT_UNALIGNED_ACCESS
@@ -228,6 +226,13 @@ config ARM64
help
ARM 64-bit (AArch64) Linux support.
+config TOOLCHAIN_SUPPORTS_DYNAMIC_FTRACE_WITH_REGS
+ def_bool y
+ depends on $(cc-option,-fpatchable-function-entry=2)
+ # https://github.com/ClangBuiltLinux/linux/issues/1507
+ depends on CC_IS_GCC || (CC_IS_CLANG && LD_IS_LLD) || (CC_IS_CLANG && LD_VERSION >= 23600)
+ select HAVE_DYNAMIC_FTRACE_WITH_REGS
+
config 64BIT
def_bool y
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2022-04-08 17:18 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-08 11:54 allmodconfig builds failing to link on arm64 Will Deacon
2022-04-08 14:45 ` Mark Rutland
2022-04-08 15:04 ` Nathan Chancellor
2022-04-08 15:06 ` Mark Rutland
2022-04-08 16:13 ` Will Deacon
2022-04-08 17:17 ` Nathan Chancellor [this message]
2022-04-08 18:37 ` Nathan Chancellor
2022-04-13 9:26 ` Will Deacon
2022-04-13 15:04 ` Nathan Chancellor
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=YlBuH2ScVeRO93AG@dev-arch.thelio-3990X \
--to=nathan@kernel.org \
--cc=ardb@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=keescook@chromium.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=mark.rutland@arm.com \
--cc=will@kernel.org \
/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