On 2026/8/11 下午10:22, Huacai Chen wrote:
Hi, Petr,
On Tue, Aug 11, 2026 at 8:20 PM Petr Pavlu <[email protected]> wrote:
On 8/11/26 9:15 AM, Tiezhu Yang wrote:
The compiler toolchains generate internal local labels on certain
architectures (such as LoongArch) for optimizations and relocations.
While these local labels are filtered out during runtime lookups in
find_kallsyms_symbol(), they still leak into the permanent symbol
tables of loaded modules, because layout_symtab() and add_kallsyms()
do not check for the mapping symbols during layout generation.
Consequently, tracing tools like bpftrace resolve identical addresses
into confusing local labels instead of actual clear C function names.
Fix this by adding is_mapping_symbol() checks directly into the symbol
tracking loops of layout_symtab() and add_kallsyms(). This prevents the
mapping symbols from entering the module's memory symbol arrays at load
time.
This optimization looks sensible to me. Kallsyms in vmlinux also
normally doesn't include information about local labels (.L<xyz>) and
mapping symbols ($a, $d, ...), so it should be ok not to track them in
modules either.
Note that the patch description mixes up these two symbol categories,
presumably because the existing is_mapping_symbol() function conflates
them as well.
...
It is better to avoid duplicating the same logic in layout_symtab() and
add_kallsyms(). The function is_core_symbol() can be renamed to
something like is_kept_symbol() and can be solely responsible for
deciding what to keep.
I'm sorry but I think Tiezhu's patch is simpler and cleaner. :)
Hi Petr and Huacai,
Thanks for your feedback! To make the code cleaner, I plan to split the
changes into the following three patches for v3:
1. module/kallsyms: Rename is_mapping_symbol() to is_local_mapping_symbol()
2. module/kallsyms: Refactor current symbol filtering into is_kept_symbol()
3. module/kallsyms: Filter out local and mapping symbols during module load
I will send out the v3 patch series soon.
Thanks,
Tiezhu
