On Thu, Aug 06, 2026 at 11:57:55AM -0400, Joe Lawrence wrote: > On 8/5/26 10:29 AM, Josh Poimboeuf wrote: > > v2: > > - rebased on tip/master (first 6 patches were merged) > > - dropped original patches 7-8 (will post followup) > > - added .klp.symid fix > > > > v1: https://lore.kernel.org/[email protected] > > > > This consolidates fixes for the klp-build issues reported by Joe over > > the last several weeks, plus some more things I found while > > testing/reviewing. > > > > Fun stuff like symbol resolution, module dependencies, alternatives. > > > > Joe Lawrence (1): > > objtool/klp: Allow new references to module exports > > > > Josh Poimboeuf (6): > > objtool/klp: Fix vmlinux .klp.symid link error for .no_trim_symbol > > symbols > > objtool/klp: Fix size of empty special section entries > > objtool/klp: Ignore replacement offset of empty x86 alternatives > > objtool/klp: Explicitly disallow patching or referencing init > > code/data > > objtool/klp: Fix cross-module klp relocation section naming > > objtool/klp: Don't match local symbols against exports > > > > tools/objtool/arch/x86/special.c | 27 ++++++++++ > > tools/objtool/include/objtool/klp.h | 10 ++-- > > tools/objtool/include/objtool/special.h | 7 +++ > > tools/objtool/klp-diff.c | 65 ++++++++++++++++++++++--- > > tools/objtool/klp-post-link.c | 53 +++++++++++--------- > > tools/objtool/klp-symid.c | 1 + > > tools/objtool/klp-sympos.c | 10 ++++ > > 7 files changed, 141 insertions(+), 32 deletions(-) > > > > These changes (and follow-up comments) look pretty good (lightly > tested). Could "objtool/klp: Fix vmlinux .klp.symid link error for > .no_trim_symbol symbols" peel off and merge sooner since it fixes a > commit just recently merged? > > Though I think there is a still gap for EXPORT_SYMBOL_FOR_MODULES > symbols: those exported that way from vmlinux would presumably need a > klp-relocation, but klp_reloc_needed() always returns false for all > vmlinux exports. Maybe we need to parse the namespace column from > Module.symvers to special case those? (At least, that is how I read the > code, I don't have full repro test cases handy.) > > This wouldn't block any of these patches, but if you are spinning a v3, > we could consider tacking that on while we're here.
Indeed, I will do a followup patch for that one. -- Josh
