On Wed, Aug 05, 2026 at 01:51:44PM -0700, Song Liu wrote: > On Wed, Aug 5, 2026 at 7:30 AM Josh Poimboeuf <[email protected]> wrote: > > > > An x86 alternative with an empty replacement, e.g. the second entry of > > > > ALTERNATIVE_2("orig", "repl", ft1, "", ft2) > > > > has a replacementlen of zero. Its replacement offset still gets a > > relocation, but the label it points at is the end of the previous > > replacement, which is also the beginning of the *next* alternative's > > replacement. The value is meaningless; get_alt_entry() already ignores > > it for that reason. > > > > klp diff doesn't ignore it. When such an alternative belongs to a > > changed function, cloning its relocations drags in the unrelated > > neighboring replacement, along with everything that replacement > > references. On an x86 clang/lto build an empty alternative in > > meminfo_proc_show() pulled in the replacement of an alternative in > > proc_kcore_init(), silently emitting a klp relocation against init text > > which has long since been freed by the time the patch is applied. > > > > Add arch_alt_ignore_new_reloc() and skip such relocations when cloning. > > This has to be arch specific: on arm64 a zero-length replacement instead > > identifies an alternative callback, whose replacement offset points at > > the callback function and must be preserved. > > > > Fixes: dd590d4d57eb ("objtool/klp: Introduce klp diff subcommand for > > diffing object files") > > Signed-off-by: Josh Poimboeuf <[email protected]> > > The patch looks good to me. > > Acked-by: Song Liu <[email protected]> > > Maybe we should add a __weak version of arch_alt_ignore_new_reloc(), > but that can wait until we add arm64 support. > > However, this reminds me the cross compile use case. With current > arch_* functions, we cannot run klp-build on x86_64 build server for > an arm64 kernel (right?). What's our plan with the cross-compile use > cases?
I suspect it will be easy, objtool already works fine being cross-compiled today. Feel free to try it ;-) -- Josh
