On Thu, Oct 09, 2025 at 10:37:36PM -0700, Nathan Chancellor wrote: > 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...
This is a very unpleasant problem, but it does not seem fatal. There will not be many such characters in the final vmlinux. In the configuration from the bug report, there are only: $ nm vmlinux.unstripped.riscv |grep -c __mod_device_table__ 17 Of course, this does not mean that the problem does not need to be solved. > Does this happen with other architectures? I have > not seen any reports yet but I have not tested anything yet. LDFLAGS_vmlinux for riscv was taken from arm64. I suspect that there may be the same problem there. But I haven't checked yet whether the problem actually exists on arm64. > Why is RISC-V special here? This problem on riscv only occurs when CONFIG_RELOCATABLE=y is specified. Without this parameter, everything will compile as expected. > 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... The aplic_acpi_match structure is indeed used, but they are used themselves, not their alias, which is generated by the MODULE_DEVICE_TABLE macro. I also asked the guys from binutils for help: https://sourceware.org/pipermail/binutils/2025-October/144782.html > 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? Yes, that would be great. Maybe I'm looking in the wrong direction, but still. On riscv: * with CONFIG_RELOCATABLE=y (where the error appears): vmlinux.unstripped: ELF 64-bit LSB shared object, UCB RISC-V, RVC, soft-float ABI, version 1 (SYSV), dynamically linked, not stripped * without CONFIG_RELOCATABLE: vmlinux.unstripped: ELF 64-bit LSB executable, UCB RISC-V, RVC, soft-float ABI, version 1 (SYSV), statically linked, not stripped On x64_64: * with and without CONFIG_RELOCATABLE=y: vmlinux.unstripped: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, not stripped -- Rgrds, legion
