All of lore.kernel.org
 help / color / mirror / Atom feed
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 11:37:24 -0700	[thread overview]
Message-ID: <YlCA5PoIjF6nhwYj@dev-arch.thelio-3990X> (raw)
In-Reply-To: <YlBuH2ScVeRO93AG@dev-arch.thelio-3990X>

On Fri, Apr 08, 2022 at 10:17:21AM -0700, Nathan Chancellor wrote:
> On Fri, Apr 08, 2022 at 05:13:44PM +0100, Will Deacon wrote:
> > 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:

A sample of what that might look like is below.

Additionally, I think I understand why this is happening now. We turned
on the integrated assembler by default in 5.15, even with just
"CC=clang", see commit f12b034afeb3 ("scripts/Makefile.clang: default to
LLVM_IAS=1"). When __patchable_function_entries was implemented in clang
10.0.0, Fangrui added a follow-up change that generated different
section flags based on whether or not the integrated assembler was being
used, due to binutils deficiencies at the time that did not exist in the
integrated assembler or ld.lld:

https://github.com/llvm/llvm-project/commit/7fa5290d5bd5632d7a36a4ea9f46e81e04fb819e

This did not account for the fact that someone might use the integrated
assembler with GNU ld. That case was rarely triggered prior to the Linux
commit though, as people would either use:

$ make CC=clang (clang, GNU as, GNU ld)
$ make LLVM=1 (clang, GNU as, ld.lld)
$ make LLVM=1 LLVM_IAS=1 (clang, integrated assembler, ld.lld)

which would mean that the integrated assembler and GNU ld were never
used together, unless someone used "CC=clang LLVM_IAS=1", which clearly
no one ever did :)

After the default change on the Linux side, we end up with:

$ make CC=clang (clang, integrated assembler, GNU ld)
$ make LLVM=1 (clang, integrated assembler, ld.lld)
$m ake LLVM=1 LLVM_IAS=1 (equivalent to above)

The first case is the one we are running into right now. I included this
assembler dependency below, which should handle clang 11 and 12 and the
follow up change in clang 13+:

https://github.com/llvm/llvm-project/commit/853a2649160c1c80b9bbd38a20b53ca8fab704e8

I'll run it through a full set of build tests and wait for some feedback
before sending formally, just to make sure I am on the right track.

Cheers,
Nathan

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 57c4c995965f..1fd16faa7f31 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,17 @@ config ARM64
 	help
 	  ARM 64-bit (AArch64) Linux support.
 
+config CLANG_SUPPORTS_DYNAMIC_FTRACE_WITH_REGS
+	def_bool CC_IS_CLANG
+	# https://github.com/ClangBuiltLinux/linux/issues/1507
+	depends on AS_IS_GNU || (AS_IS_LLVM && (LD_IS_LLD || LD_VERSION >= 23600))
+	select HAVE_DYNAMIC_FTRACE_WITH_REGS
+
+config GCC_SUPPORTS_DYNAMIC_FTRACE_WITH_REGS
+	def_bool CC_IS_GCC
+	depends on $(cc-option,-fpatchable-function-entry=2)
+	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

  reply	other threads:[~2022-04-08 18:38 UTC|newest]

Thread overview: 10+ 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:04     ` Nathan Chancellor
2022-04-08 15:06   ` Mark Rutland
2022-04-08 16:13     ` Will Deacon
2022-04-08 17:17       ` Nathan Chancellor
2022-04-08 18:37         ` Nathan Chancellor [this message]
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=YlCA5PoIjF6nhwYj@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.