On Tue, Aug 26, 2025 at 10:02:31PM -0700, Eduard Zingerman wrote: > On Tue, 2025-08-26 at 13:17 -0700, Yonghong Song wrote: > > [...] > > > I tried with gcc14 and can reproduced the issue described in the above. > > I build the kernel like below with gcc14 > > make KCFLAGS='-O3' -j > > and get the following build error > > WARN: resolve_btfids: unresolved symbol bpf_strnchr > > make[2]: *** [/home/yhs/work/bpf-next/scripts/Makefile.vmlinux:91: vmlinux] Error 255 > > make[2]: *** Deleting file 'vmlinux' > > Checking the symbol table: > > 22276: ffffffff81b15260 249 FUNC LOCAL DEFAULT 1 bpf_strnchr.cons[...] > > 235128: ffffffff81b1f540 296 FUNC GLOBAL DEFAULT 1 bpf_strnchr > > and the disasm code: > > bpf_strnchr: > > ... > > > > bpf_strchr: > > ... > > bpf_strnchr.constprop.0 > > ... > > > > So in symbol table, we have both bpf_strnchr.constprop.0 and bpf_strnchr. > > For such case, pahole will skip func bpf_strnchr hence the above resolve_btfids > > failure. > > > > The solution in this patch can indeed resolve this issue. > > It looks like instead of adding __noclone there is an option to > improve pahole's filtering of ambiguous functions. > Abstractly, there is nothing wrong with having a clone of a global > function that has undergone additional optimizations. As long as the > original symbol exists, everything should be fine. > > Since kfuncs are global, this should guarantee that the compiler does not > change their signature, correct? Does this also hold for LTO builds? > If so, when pahole sees a set of symbols like [foo, foo.1, foo.2, ...], > with 'foo' being global and the rest local, then there is no real need > to filter out 'foo'. > > Wdyt? I think we should do both: fix resolve_btfids to ignore compiler optimization suffixes (.isra., .constprop., .part., .cold, ...) and add __noclone. This feels like the safest path IMHO. Fixing resolve_btfids alone works with current compilers, but future compiler versions, under aggressive IPA/LTO optimizations, might decide that the main global symbol is redundant and drop it altogether, leading to similar issues. Basically, fixing the tool makes the BTF pipeline more robust, adding __noclone also makes the exported symbols themselves more robust, regardless of compiler optimizations. Thanks, -Andrea
