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

[Alexey Gladkov <legion@kernel.org>]

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