allmodconfig builds failing to link on arm64

allmodconfig builds failing to link on arm64

[Will Deacon]

Hi folks,

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.

Is anybody else having problems? The linker error is useless enough that I
haven't found time to dig any further into it and the build robots haven't
reported any failures to my knowledge. The only similar report I found in
the archive is:

https://lore.kernel.org/all/85bfe02c-9432-c5b0-04e0-8096adf37b93@gmx.com/#t

which apparently went away after a make clean whereas mine persists.

Will

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: allmodconfig builds failing to link on arm64

[Mark Rutland]

On Fri, Apr 08, 2022 at 12:54:07PM +0100, Will Deacon wrote:
> Hi folks,

Hi Will,

> 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.

Thanks,
Mark.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: allmodconfig builds failing to link on arm64

[Nathan Chancellor]

Hi Will and Mark,

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:
> > Hi folks,
> 
> Hi Will,
> 
> > 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.

Correct, it sounds like it is 2.36 where this issue disappears:

https://github.com/ClangBuiltLinux/linux/issues/1507

https://sourceware.org/bugzilla/show_bug.cgi?id=26256

I don't know if something changed in LLVM to cause this but if it did,
it has clearly been there since LLVM 11, so it is probably not worth
hunting down. Unfortunately, our testing with just "CC=clang" has been
lacking, as we are primarily focused on using the whole LLVM suite, so
this could have been around for a while and we just missed it.

It sounds like this same issue would be seen with GCC 11+ and older
binutils but I am guessing that combination is not quite as common, as
GCC 11.1 was released April 2021 and binutils 2.36 had been out for
three months at that point.

> I don't know why this suddenly became a problem in v5.18-rc1; I'll have
> a look.

Yes, this part is odd, because according to our issue above, this has
been visible for a couple releases. Perhaps some configuration change
allows CONFIG_FTRACE and CONFIG_STACK_TRACER to be turned on with
allmodconfig now?

I think we can probably work around this in Kconfig fairly easily, I can
take a look at that today if necessary.

Cheers,
Nathan

Re: allmodconfig builds failing to link on arm64

[Nathan Chancellor]

Hi Will and Mark,

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:
> > Hi folks,
> 
> Hi Will,
> 
> > 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.

Correct, it sounds like it is 2.36 where this issue disappears:

https://github.com/ClangBuiltLinux/linux/issues/1507

https://sourceware.org/bugzilla/show_bug.cgi?id=26256

I don't know if something changed in LLVM to cause this but if it did,
it has clearly been there since LLVM 11, so it is probably not worth
hunting down. Unfortunately, our testing with just "CC=clang" has been
lacking, as we are primarily focused on using the whole LLVM suite, so
this could have been around for a while and we just missed it.

It sounds like this same issue would be seen with GCC 11+ and older
binutils but I am guessing that combination is not quite as common, as
GCC 11.1 was released April 2021 and binutils 2.36 had been out for
three months at that point.

> I don't know why this suddenly became a problem in v5.18-rc1; I'll have
> a look.

Yes, this part is odd, because according to our issue above, this has
been visible for a couple releases. Perhaps some configuration change
allows CONFIG_FTRACE and CONFIG_STACK_TRACER to be turned on with
allmodconfig now?

I think we can probably work around this in Kconfig fairly easily, I can
take a look at that today if necessary.

Cheers,
Nathan

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: allmodconfig builds failing to link on arm64

[Mark Rutland]

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:
> > Hi folks,
> 
> Hi Will,
> 
> > 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.

Thanks,
Mark.

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: allmodconfig builds failing to link on arm64

[Will Deacon]

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.

Cheers,

Will

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: allmodconfig builds failing to link on arm64

[Nathan Chancellor]

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

Re: allmodconfig builds failing to link on arm64

[Nathan Chancellor]

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

Re: allmodconfig builds failing to link on arm64

[Will Deacon]

Hi Nathan,

On Fri, Apr 08, 2022 at 11:37:24AM -0700, Nathan Chancellor wrote:
> On Fri, Apr 08, 2022 at 10:17:21AM -0700, Nathan Chancellor wrote:
> 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

FWIW, I can confirm that this fixes the problem for me:

Tested-by: Will Deacon <will@kernel.org.

Do you plan to post as a separate patch?

Will

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: allmodconfig builds failing to link on arm64

[Nathan Chancellor]

On Wed, Apr 13, 2022 at 10:26:14AM +0100, Will Deacon wrote:
> Hi Nathan,
> 
> On Fri, Apr 08, 2022 at 11:37:24AM -0700, Nathan Chancellor wrote:
> > On Fri, Apr 08, 2022 at 10:17:21AM -0700, Nathan Chancellor wrote:
> > 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
> 
> FWIW, I can confirm that this fixes the problem for me:
> 
> Tested-by: Will Deacon <will@kernel.org.
> 
> Do you plan to post as a separate patch?

Yes, I will go ahead and type up a proper commit message and ship it
along shortly, thanks for the feedback!

Cheers,
Nathan

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel