Problem with stripping symbols in linux kernel on riscv64

[Alexey Gladkov]

On Fri, Oct 10, 2025 at 10:20:04AM +0800, Nelson Chu wrote:
> I guess, if enable relaxations, the code may be shrinked, the symbols may
> be changed after linking, so we need relocations if we want to get the
> values of the symbols.  It seems weird that the kernel code never used the
> alias symbols, but still have relocations for them.

I found possible reason. I compared the is_weakalias processing code in
bfd/elfnn-aarch64.c, bfd/elfxx-x86.c and bfd/elfnn-riscv.c. The riscv does
not support nocopyreloc, which is available for aarch64 and x86.

Just for illustration the following processing is missing (completely
untested patch):

diff --git a/bfd/elfnn-riscv.c b/bfd/elfnn-riscv.c
index 09cf7076733..f88affe3f4e 100644
--- a/bfd/elfnn-riscv.c
+++ b/bfd/elfnn-riscv.c
@@ -1331,6 +1331,8 @@ riscv_elf_adjust_dynamic_symbol (struct bfd_link_info *info,
       BFD_ASSERT (def->root.type == bfd_link_hash_defined);
       h->root.u.def.section = def->root.u.def.section;
       h->root.u.def.value = def->root.u.def.value;
+      if (ELIMINATE_COPY_RELOCS || info->nocopyreloc)
+       h->non_got_ref = def->non_got_ref;
       return true;
     }

> You probably can check where and who tries to get the value of these
> alias symbols?

No one uses them. It is exclusively a service name, so that later you can
find the target by a predefined name. That is why __attribute__((used)) is
added for them.

> Which relocation types? R_RISCV_PCREL_HI20/LO12 or R_RISCV_32/64?

All alias symbols have type R_RISCV_64. The targets of these aliases have
the same type.

> If fromer then still has code try to access the aliases, if later then
> probably you enable the debug mode.
> 
> Nelson
> 
> On Fri, Oct 10, 2025 at 1:23 AM Alexey Gladkov <legion@kernel.org> wrote:
> 
> > Greetings!
> >
> > I faced a problem when compiling the linux kernel [1]. The kernel uses
> > symbols with special names to generate modaliases [2]. These symbols are
> > aliases for real data structures used by the kernel. These aliases
> > themselves are never used in the kernel code. These symbols are only
> > needed for post-generation.
> >
> > After generating modalias these symbols are removed. It works, but for
> > some reason, in some cases, this does not work. The problem only occurs
> > with CONFIG_RELOCATABLE=y on riscv64.
> >
> > I compared the builds on x86_64 and riscv64. At first glance, everything
> > looks the same and the symbols end up in the same sections.
> >
> >
> > $ objdump -x vmlinux.unstripped.x86_64 | grep ffffffff81ef4dc0
> > ffffffff81ef4dc0 l O .rodata 0000000000000258 kbd_ids
> > ffffffff81ef4dc0 l O .rodata 0000000000000258
> > __mod_device_table__kmod_keyboard__input__kbd_ids
> >
> > $ objcopy \
> >     --strip-symbol=__mod_device_table__kmod_keyboard__input__kbd_ids \
> >     vmlinux.unstripped.x86_64 vmlinux.unstripped.x86_64.strip
> >
> > $ objdump -x vmlinux.unstripped.x86_64.strip | grep ffffffff81ef4dc0
> > ffffffff81ef4dc0 l O .rodata 0000000000000258 kbd_ids
> >
> >
> > However, for riscv64 with CONFIG_RELOCATABLE=y, an error occurs:
> >
> > $ objdump -x vmlinux.unstripped.riscv |grep ffffffff80c637e0
> > ffffffff80c637e0 l O .rodata 0000000000000258
> > __mod_device_table__kmod_keyboard__input__kbd_ids
> > ffffffff80c637e0 l O .rodata 0000000000000258 kbd_ids
> >
> > $ riscv64-unknown-linux-gnu-objcopy \
> >     --strip-symbol=__mod_device_table__kmod_keyboard__input__kbd_ids \
> >     vmlinux.unstripped.riscv vmlinux.unstripped.riscv.strip
> > riscv64-unknown-linux-gnu-objcopy: not stripping symbol
> > `__mod_device_table__kmod_keyboard__input__kbd_ids' because it is named in
> > a relocation
> >
> >
> > I'm not sure where the problem is. I would be very grateful for any help
> > in finding it.
> >
> >
> > [1]
> > https://lore.kernel.org/all/20251007011637.2512413-1-cmirabil@redhat.com/
> > [2]
> > https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/linux/module.h#n260
> > [3]
> > https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=binutils/objcopy.c;h=3c1bcf622ff2c813276109c626bfb7711c5ccc77;hb=HEAD#l1647
> >
> > --
> > Rgrds, legion
> >
> >

-- 
Rgrds, legion