On Thu, Oct 09, 2025 at 09:52:08PM +0200, Nicolas Schier wrote:
> On Tue, Oct 07, 2025 at 12:15:21PM +0200, Alexey Gladkov wrote:
> > Hm. Indeed. I haven't found a good solution yet, but you can use the
> > following patch to unlock compilation. It won't solve the problem, it will
> > only hide it.
> >
> > --- a/scripts/Makefile.vmlinux
> > +++ b/scripts/Makefile.vmlinux
> > @@ -84,7 +84,7 @@ endif
> > remove-section-y := .modinfo
> > remove-section-$(CONFIG_ARCH_VMLINUX_NEEDS_RELOCS) += '.rel*'
> >
> > -remove-symbols := -w --strip-symbol='__mod_device_table__*'
> > +remove-symbols := -w --strip-unneeded-symbol='__mod_device_table__*'
> >
> > # To avoid warnings: "empty loadable segment detected at ..." from GNU
> > objcopy,
> > # it is necessary to remove the PT_LOAD flag from the segment.
> >
>
> Is it problematic to hide that? Otherwise we'd have to revert the
> patch, right?
Yeah, I would much prefer to ending up with pointless
__mod_device_table__ symbols in the final binary than erroring out
during the build... Does this happen with other architectures? I have
not seen any reports yet but I have not tested anything yet. Why is
RISC-V special here?
It seems like the relocation comes from the .LASANLOC4 symbol in
.data.rel.local?
$ llvm-objdump -Dr drivers/irqchip/irq-riscv-aplic-main.o
...
Disassembly of section .data.rel.local:
...
0000000000000130 <.LASANLOC4>:
...
1c0: 0000 unimp
00000000000001c0: R_RISCV_64
__mod_device_table__kmod_irq_riscv_aplic_main__acpi__aplic_acpi_match
...
I cannot find much information about this ASANLOC outside of its
location within the GCC sources, do we even need it? I don't see a way
to opt out of this section altogether or on a per-variable basis, I
wonder if there is some way to strip it out...
I plan to send the initial 6.18 Kbuild fixes pull request on Saturday.
If we cannot figure out a real solution before then, maybe we can just
switch to '--strip-unneeded-symbol' with a comment to upgrade that to
'--strip-symbol' when possible?
Cheers,
Nathan
