allmodconfig builds failing to link on arm64

Nathan Chancellor nathan at kernel.org
Fri Apr 8 11:37:24 PDT 2022


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
 



More information about the linux-arm-kernel mailing list