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? > > > > Also, LTO may generate symbols like: > > > > The "also" is a clue that this should probably be two separate patches. > > > > Also, for objtool patches, please prefix the subject with "objtool:", or > > in this case, for klp-specific code, "objtool/klp:". > > > > > __UNIQUE_ID_addressable___UNIQUE_ID_pci_invalid_bar_694_695 > > > > > > Remove trailing '_' together with numbers and '.' so that both numbers > > > added to the end of the symbol are removed. For example, the above s > > > ymbol will be demangled as > > > > > > __UNIQUE_ID_addressable___UNIQUE_ID_pci_invalid_bar > > > > This is indeed a bug in demangle_name(), but not specific to LTO. The > > unique number is added by the __UNIQUE_ID() macro. > > > > I guess in this case LTO is doing some kind of nested __UNIQUE_ID() to > > get two "__UNIQUE_ID" strings and two numbers? But the bug still exists > > for the non-nested case. > > I don't see nested __UNIQUE_ID() without LTO. Both gcc and clang without > LTO only sees one level of __UNIQUE_ID. > > With one level of __UNIQUE_ID(), existing code works fine. We just get one > extra "_" at the end of the demanged_name. Ah, I see. -- Josh
