On Tue, Feb 3, 2026 at 5:24 PM Josh Poimboeuf <[email protected]> wrote: > > On Tue, Feb 03, 2026 at 04:24:06PM -0800, Song Liu wrote: > > On Tue, Feb 3, 2026 at 3:53 PM Josh Poimboeuf <[email protected]> wrote: > > > > > > On Tue, Feb 03, 2026 at 01:40:06PM -0800, Song Liu wrote: > > > > With CONFIG_LTO_CLANG_THIN, __UNIQUE_ID_* can be global. Therefore, it > > > > is necessary to demangle global symbols. > > > > > > Ouch, so LTO is changing symbol bindings :-/ > > > > > > If a patch causes a symbol to change from LOCAL to GLOBAL between the > > > original and patched builds, that will break some fundamental > > > assumptions in the correlation logic. > > > > This can indeed happen. A function can be "LOCAL DEFAULT" XXXX > > in original, and "GLOBAL HIDDEN" XXXX.llvm.<hash> in patched. > > > > I am trying to fix this with incremental steps. > > > > > Also, notice sym->demangled_name isn't used for correlating global > > > symbols in correlate_symbols(). That code currently assumes all global > > > symbols are uniquely named (and don't change between orig and patched). > > > So this first fix seems incomplete. > > > > We still need to fix correlate_symbols(). I am not 100% sure how to do > > that part yet. > > > > OTOH, this part still helps. This is because checksum_update_insn() > > uses demangled_name. After the fix, if a function is renamed from > > XXXX to XXXX.llvm.<hash> after the patch, functions that call the > > function are not considered changed. > > Hm, wouldn't that still leave the .llvm at the end?
E.. Right. I described a different case. The actual case being fixed here is when foo.llvm.<hash_1> got changed to foo.llvm.<hash_2>. Let me think more about all the cases and have a better solution. Thanks, Song
