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/cover.1785727106.git.jpoimboe@kernel.org
> >
> > 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