On Fri, Oct 10, 2025 at 1:37 AM Nathan Chancellor <[email protected]> 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... 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...
It seems from reading the gcc source that these are emitted to contain information about where global declarations came from, presumably to allow nicer ASAN error messages. (i.e. memory corruption affected this symbol defined here). I don't think that KASAN uses these, but I am not sure. I also don't know how they could be removed. I found a hit using grep.app https://grep.app/search?case=true&q=ASANLOC in the apache/nuttx repository where they seem to be doing something with these symbols in a linker script, but I am not familiar enough with linker scripts, or that project to fully understand what is going on. > > 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 >
