On Wed, Feb 18, 2026 at 07:08:55PM -0800, Song Liu wrote: > On Wed, Feb 18, 2026 at 3:00 PM Joe Lawrence <[email protected]> wrote: > > > > On Thu, Feb 12, 2026 at 11:21:53AM -0800, Song Liu wrote: > [...] > > vmlinux.o: warning: objtool: correlate c_start.llvm.15251198824366928061 > > (origial) to c_start.llvm.14107081093236395767 (patched) > > vmlinux.o: warning: objtool: correlate c_stop.llvm.15251198824366928061 > > (origial) to c_stop.llvm.14107081093236395767 (patched) > > vmlinux.o: warning: objtool: correlate c_next.llvm.15251198824366928061 > > (origial) to c_next.llvm.14107081093236395767 (patched) > > vmlinux.o: warning: objtool: correlate > > show_cpuinfo.llvm.15251198824366928061 (origial) to > > show_cpuinfo.llvm.10047843810948474008 (patched) > > vmlinux.o: warning: objtool: correlate .str.llvm.1768504738091882651 > > (origial) to .str.llvm.7814622528726587167 (patched) > > vmlinux.o: warning: objtool: correlate > > crypto_seq_ops.llvm.1768504738091882651 (origial) to > > crypto_seq_ops.llvm.14107081093236395767 (patched) > > vmlinux.o: warning: objtool: correlate c_start.llvm.1768504738091882651 > > (origial) to c_start.llvm.14107081093236395767 (patched) > > vmlinux.o: warning: objtool: correlate c_stop.llvm.1768504738091882651 > > (origial) to c_stop.llvm.14107081093236395767 (patched) > > vmlinux.o: warning: objtool: correlate c_next.llvm.1768504738091882651 > > (origial) to c_next.llvm.14107081093236395767 (patched) > > vmlinux.o: warning: objtool: correlate c_show.llvm.1768504738091882651 > > (origial) to c_show.llvm.14107081093236395767 (patched) > > vmlinux.o: warning: objtool: correlate > > __pfx_c_start.llvm.15251198824366928061 (origial) to > > __pfx_c_start.llvm.14107081093236395767 (patched) > > vmlinux.o: warning: objtool: correlate > > __pfx_c_stop.llvm.15251198824366928061 (origial) to > > __pfx_c_stop.llvm.14107081093236395767 (patched) > > vmlinux.o: warning: objtool: correlate > > __pfx_c_next.llvm.15251198824366928061 (origial) to > > __pfx_c_next.llvm.14107081093236395767 (patched) > > vmlinux.o: warning: objtool: correlate > > __pfx_show_cpuinfo.llvm.15251198824366928061 (origial) to > > __pfx_show_cpuinfo.llvm.10047843810948474008 (patched) > > vmlinux.o: warning: objtool: correlate > > __pfx_c_start.llvm.1768504738091882651 (origial) to > > __pfx_c_start.llvm.14107081093236395767 (patched) > > vmlinux.o: warning: objtool: correlate > > __pfx_c_stop.llvm.1768504738091882651 (origial) to > > __pfx_c_stop.llvm.14107081093236395767 (patched) > > vmlinux.o: warning: objtool: correlate > > __pfx_c_next.llvm.1768504738091882651 (origial) to > > __pfx_c_next.llvm.14107081093236395767 (patched) > > vmlinux.o: warning: objtool: correlate > > __pfx_c_show.llvm.1768504738091882651 (origial) to > > __pfx_c_show.llvm.14107081093236395767 (patched) > > vmlinux.o: warning: objtool: no correlation: > > c_start.llvm.1768504738091882651 > > vmlinux.o: warning: objtool: no correlation: c_stop.llvm.1768504738091882651 > > vmlinux.o: warning: objtool: no correlation: c_next.llvm.1768504738091882651 > > vmlinux.o: new function: c_start.llvm.10047843810948474008 > > vmlinux.o: new function: c_stop.llvm.10047843810948474008 > > vmlinux.o: new function: c_next.llvm.10047843810948474008 > > vmlinux.o: changed function: c_start.llvm.14107081093236395767 > > vmlinux.o: changed function: c_stop.llvm.14107081093236395767 > > vmlinux.o: changed function: c_next.llvm.14107081093236395767 > > Building patch module: livepatch-min.ko > > SUCCESS > > Thanks for the test case. This one shows the worst case of the .llvm. > suffix issue. > > We have > c_start.llvm.15251198824366928061 > c_start.llvm.1768504738091882651 > in the original kernel, and > c_start.llvm.14107081093236395767 > c_start.llvm.10047843810948474008 > in the patched kernel. > > All of them are GLOBAL HIDDEN functions, so I don't think we can > reliably correlate them. Maybe we should fail the build in such cases.
I'm thinking the "correlate <orig> to <patched>" warnings would need to be an error when there's ambiguity (i.e., two symbols with the same ".llvm.*" mangled name), as there's nothing preventing their symbols' orders from getting swapped. And note that changing a symbol from local to global (or vice versa) can do exactly that, as globals always come at the end. Also, this problem may be more widespread than the above, as there are a lot of duplicately named functions in the kernel, with CONFIG_DEBUG_SECTION_MISMATCH making the problem even worse in practice. I think we may need to figure out a way to map sym.llvm.<hash> back to its original FILE symbol so correlate_symbols() can reliably disambiguate. The hash seems to be file-specific. I don't think there's a way for objtool to reverse engineer that. DWARF could be used to map the symbol to its original file name, but we can't necessarily rely on CONFIG_DEBUG_INFO. However, I did find that LLVM has a hidden option: -mllvm -use-source-filename-for-promoted-locals which changes the hash to a file path: c_start.llvm.arch_x86_kernel_cpu_proc_c That would be (almost) everything we'd need to match a symbol to its FILE symbol. The only remaining ambiguity is that FILE symbols only have the basename, not the full path. So a duplicate "basename+sym" would still be ambiguous. But that seems much less likely. We could possibly enforce a new requirement that "basename+sym" be unique treewide. Then we could maybe even base sympos on that. That also might help fix some of the other unique symbol headaches I remember some people having with tracing and possibly elsewhere. -- Josh
