Re: [REGRESSION] mainline/master: (build) in arch/arm/kernel/entry-common.o (/tmp/kci/linux/scripts/Makefile...

On Tue, 18 Aug 2026, at 20:52, Nathan Chancellor wrote:
> On Tue, Aug 18, 2026 at 09:51:21AM -0700, Nathan Chancellor wrote:
>> On Tue, Aug 18, 2026 at 09:19:04AM -0700, Nick Desaulniers wrote:
>> > + Ard
>> > 
>> > On Mon, Aug 17, 2026 at 11:00 PM Thorsten Leemhuis
>> > <[email protected]> wrote:
>> > > Nathan, Nick, do you still care about clang problems like this?
>> > 
>> > Yes, from the logs, it looks like ARCH=arm allmodconfig with clang-21
>> > (perhaps, there's a funny warning about the compiler version in the
>> > logs).
>> > 
>> > > And do
>> > > you by chance know what's wrong here?
>> > >
>> > > """
>> > > <instantiation>:2:11: error: out of range pc-relative fixup value
>> > >  ldr r10, =__per_cpu_offset
>> > >           ^
>> > > <instantiation>:2:11: error: out of range pc-relative fixup value
>> > >  ldr tsk, =__current
>> > >           ^
>> > > <instantiation>:2:11: error: out of range pc-relative fixup value
>> > >  ldr tsk, =__current
>> > >           ^
>> > 
>> > Smells like the same problem that was addressed by
>> > commit 5fe41793bc78 ("ARM: 9176/1: avoid literal references in inline assembly")
>> > 
>> > What tree was being tested? 5fe41793bc78 landed in v5.18-rc1. Whatever
>> > was being tested is probably missing that patch.
>> 
>> As Mark notes, this is mainline. This error is visible with LLVM 23 as
>> well. I bisected it to commit 79d27fd71854 ("arch: hookup fchroot()
>> system call").
>> 
>> I do see that change in -next and there is no error there so was this a
>> known issue that was fixed in another tree? I will keep looking.
>
> It looks like commit 25900bd99d4d ("ARM: limit OABI support to StrongARM
> CPUs") in the soc tree avoids this error by disabling CONFIG_OABI_COMPAT
> for allmodconfig. If I disable that on top of allmodconfig with current
> mainline, the error goes away.
>
> I narrowed down a reproducer to
>
>   $ cat arch/arm/configs/repro.config
>   CONFIG_ARCH_MULTI_V6=y
>   CONFIG_ARCH_REALVIEW=y
>   CONFIG_COMPILE_TEST=y
>   CONFIG_MACH_REALVIEW_PB1176=y
>   CONFIG_OABI_COMPAT=y
>
>   $ make -skj"$(nproc)" ARCH=arm LLVM=1 mrproper defconfig repro.config 
> arch/arm/kernel/entry-common.o
>   <instantiation>:2:11: error: out of range pc-relative fixup value
>    ldr r10, =__per_cpu_offset
>             ^
>   <instantiation>:2:11: error: out of range pc-relative fixup value
>    ldr tsk, =__current
>             ^
>   <instantiation>:2:11: error: out of range pc-relative fixup value
>    ldr tsk, =__current
>             ^
>
> CONFIG_COMPILE_TEST is necessary because it turns off
> CONFIG_ARM_HAS_GROUP_RELOCS, which seems relevant here.
>

We're falling back to the mov_l asm macro in this case.

This is unfortunate, because the only reason to avoid these group
relocations is making allyesconfig work, now that LLD has caught up.

I did not manage to reproduce this, but if this is something we care
deeply about, we might tweak mov_l as below when COMPILE_TEST is set,
so that the literal pool is always in range.


--- a/arch/arm/include/asm/assembler.h
+++ b/arch/arm/include/asm/assembler.h
@@ -636,6 +636,12 @@
        .macro          mov_l, dst:req, imm:req, cond
        .if             __LINUX_ARM_ARCH__ < 7
        ldr\cond        \dst, =\imm
+#ifdef CONFIG_COMPILE_TEST
+       /* The literal may go out of range in pathological cases */
+       b               .L\@
+       .ltorg
+.L\@:
+#endif
        .else
        movw\cond       \dst, #:lower16:\imm
        movt\cond       \dst, #:upper16:\imm