Re: [PATCH v8 7/8] modpost: Create modalias for builtin modules

[Nathan Chancellor <nathan@kernel.org>]

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