On Thu, Feb 19, 2026 at 12:51 PM Josh Poimboeuf <[email protected]> wrote: [...] > > > > 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.
Agreed. I changed the logic to error out when there is ambiguity. > 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. I am aware of this option. I think it makes kallsyms too ugly tough. Also, at the moment, llvm adds these suffixes even when there is no ambiguity. As a result, there are too many of them. Yonghong is working on a LLVM change so that it only adds suffixes when necessary (https://github.com/llvm/llvm-project/pull/178587). But this won't be available until LLVM-23. At the moment, I think error out on ambiguity is probably good enough. This should not happen too often in real world patches. Does this sound like a viable solution for now? Thanks, Song [...]
