linux-toradex.git/tools/objtool/tests/generic, branch master

objtool/klp: Add test for ThinLTO symbols sharing a demangled name

2026-09-21T09:12:08+00:00

A file-local symbol which ThinLTO has to make visible is renamed
helper.llvm..  With two such helpers in one link, the original and
the patched object hold two each, all four spelled differently, and
demangling gives "helper" for every one of them -- so the name alone cannot
say which corresponds to which.

Three translation units, two with a static helper of the same name and a
third calling into both, which is what forces the promotion.  Only one
helper changes: paired correctly that means exactly one is cloned, and
paired the wrong way round the other is, or both are.  Had both bodies
changed, both would be cloned either way and the test would prove nothing
-- which is how the first version of this was written.

The outcome is asserted, not the machinery.  With the clang tested here the
pairing survives disabling the .llvm. suffix map and stubbing out
llvm_suffix() entirely, so no single-line sabotage distinguishes it; the
tiered matcher this case was written for is not needed for this shape.  The
test says so rather than implying otherwise.

Assisted-by: Claude:claude-opus-4
Based-on-test-by: Joe Lawrence 
Assisted-by: Claude:claude-opus-5
Signed-off-by: Song Liu 
Signed-off-by: Josh Poimboeuf 
Signed-off-by: Ingo Molnar 
Link: https://patch.msgid.link/20260916184351.2720310-59-song@kernel.org

objtool/klp: Add test for Clang switch jump tables

2026-09-21T09:12:08+00:00

For a dense enough switch Clang emits the targets as a table in
.rodata..Lswitch.table. -- named after the function but not part
of it.  The patched function indexes into that table, so a clone which does
not bring it along jumps through whatever the kernel's copy holds, which
after a patch that changed the switch is the wrong set of targets.  An
indirect jump to a stale address reports nothing at build or load time.

The fixture asserts its own premise twice over, since both halves depend on
what this Clang chose to do: that a table was built rather than a chain of
comparisons, and that the added case actually changed it.

objtool has no switch-specific code -- the table is carried by the general
mechanism for data a cloned function references -- so this guards that
mechanism reaching an easily-mishandled shape rather than a particular
line, and the test says so.  Making the table uncorrelated, the nearest
available sabotage, does not change the outcome.

Assisted-by: Claude:claude-opus-4
Based-on-test-by: Joe Lawrence 
Assisted-by: Claude:claude-opus-5
Signed-off-by: Song Liu 
Signed-off-by: Josh Poimboeuf 
Signed-off-by: Ingo Molnar 
Link: https://patch.msgid.link/20260916184351.2720310-58-song@kernel.org

objtool/klp: Add test for UBSAN metadata in an unchanged function

2026-09-21T09:12:08+00:00

Every instrumented operation gets a per-callsite metadata object in an
anonymous data section -- .data..Lubsan_data and .data..Lubsan_type from
GCC, .data..L__unnamed_ from Clang -- whose names are compiler-generated
and mean nothing across a rebuild.  is_uncorrelated_section() exists so klp
diff does not try to pair them up, and nothing tested it.

The failure it prevents is a false positive, which is the direction this
suite has least coverage of.  Metadata belonging to a function nobody
touched compares as different and drags that function into the patch.  That
is not a build failure: it is a larger livepatch than intended, pulling in
dependencies with it, and every extra function is one more that can fail to
correlate or to apply.

The fixture is built with -fsanitize=shift, which both compilers
instrument; neither emits a bounds check for an index it can prove in
range.  One function changes, the other is byte-identical and carries
instrumentation of its own, and the test asserts the second is left alone.

Verified by removing each rule from is_uncorrelated_section() in turn,
which splits neatly by toolchain: dropping the .data..Lubsan rule fails the
test under gcc, dropping .data..L__unnamed_ fails it under clang.  One
test, two code paths, each checked by the compiler that reaches it.

Assisted-by: Claude:claude-opus-4
Based-on-test-by: Joe Lawrence 
Assisted-by: Claude:claude-opus-5
Signed-off-by: Song Liu 
Signed-off-by: Josh Poimboeuf 
Signed-off-by: Ingo Molnar 
Link: https://patch.msgid.link/20260916184351.2720310-57-song@kernel.org

objtool/klp: Add test for absolute and __ADDRESSABLE symbols

2026-09-21T09:12:08+00:00

A SHN_ABS symbol has no section, so any walk of sym->sec which does not
check dereferences NULL, and the kernel has plenty of them -- from linker
scripts and from .set in assembly.  __ADDRESSABLE() emits a pointer into
.discard.addressable purely to keep a symbol referenced; it means nothing
to a livepatch and is discarded at link time, but it is a relocation like
any other and gets looked at.

Neither is what the patch changes.  What this guards against is not a wrong
answer but a crash or an error on input the kernel produces routinely,
which would make every function near one unpatchable.

Not isolated to a single line, and the test says so: the absolute symbol
here has zero length, so it is excluded before the section check is reached
and removing that check alone changes nothing observable.

Assisted-by: Claude:claude-opus-4
Based-on-test-by: Joe Lawrence 
Assisted-by: Claude:claude-opus-5
Signed-off-by: Song Liu 
Signed-off-by: Josh Poimboeuf 
Signed-off-by: Ingo Molnar 
Link: https://patch.msgid.link/20260916184351.2720310-56-song@kernel.org

objtool/klp: Add test for a patch which strips a data annotation

2026-09-21T09:12:07+00:00

klp diff needs entry boundaries for a special section: either an entsize,
or ANNOTATE_DATA_SPECIAL annotations naming where each entry starts.
.static_call_sites has no entsize, so the annotations are all there is --
and a patch can remove the last one in a translation unit while leaving the
section itself in place, so that only the patched side has lost them.

The section still has to be handled.  Dropping it leaves the patched
function's static call unregistered; misreading its boundaries attaches the
entry to the wrong code.  Neither is reported at build time.

Give the fixture a NO_ANNOTATE knob and assert the premise -- annotation
present in the original, absent in the patched object, section present in
both -- before asserting the result.

Fixed by commit 3de711fba73a ("objtool/klp: Fix create_fake_symbols()
skipping entsize-based sections").  Verified by making klp diff skip
.static_call_sites when cloning special sections: the test fails.

Assisted-by: Claude:claude-opus-4
Based-on-test-by: Joe Lawrence 
Assisted-by: Claude:claude-opus-5
Signed-off-by: Song Liu 
Signed-off-by: Josh Poimboeuf 
Signed-off-by: Ingo Molnar 
Link: https://patch.msgid.link/20260916184351.2720310-55-song@kernel.org

objtool/klp: Add test for the alignment of cloned data sections

2026-09-21T09:12:07+00:00

A cloned data section has to keep its sh_addralign.  Plenty of kernel data
is aligned for correctness rather than speed -- per-CPU variables, anything
touched by an aligned vector move, structures padded to own a cacheline --
and a clone that lands under-aligned either faults on first use or silently
shares a line it was laid out to avoid.  Neither shows up until the patch
is loaded on hardware that cares.

The fixture's data is new in the patched build, so klp diff has to clone it
rather than reference the kernel's copy, and it asserts that premise before
asserting the result.

Commit 2f2600decb30 ("objtool/klp: fix data alignment in __clone_symbol()")
cannot be reverted to check this -- the revert is a no-op against the
current code, which has been rewritten since.  Verified instead by forcing
the clone's alignment to 1, which the test reports as "alignment 1,
expected 64".

Assisted-by: Claude:claude-opus-4
Based-on-test-by: Joe Lawrence 
Assisted-by: Claude:claude-opus-5
Signed-off-by: Song Liu 
Signed-off-by: Josh Poimboeuf 
Signed-off-by: Ingo Molnar 
Link: https://patch.msgid.link/20260916184351.2720310-54-song@kernel.org

objtool/klp: Add test for instruction operand checksums

2026-09-21T09:12:07+00:00

checksum_update_insn() hashes an instruction's bytes and then what any
relocation on it refers to: a string section contributes the string's
contents, anything else the target symbol's name and adjusted addend, with
a reference to a static resolved through its section symbol first.

None of that shows up in the bytes.  A rel32 operand is zero in the object
and supplied by the relocation, so calling a different function, editing a
literal the code passes, or reading a different index of an array all leave
the encoded instruction byte-identical.  A checksum stopping at the bytes
reports the function unchanged and the patch silently does not contain the
fix.

test-checksum-position is the other half: what must *not* change the
checksum when a function merely moves.

Each of the four is verified by sabotaging the line it covers.  The static
case needed a writer the compiler cannot see through -- without one it
proves the array is never written, folds every read to zero, and emits no
relocation at all, so the reference under test does not exist and the
variant passes having compared two identical objects.

Assisted-by: Claude:claude-opus-4
Based-on-test-by: Joe Lawrence 
Assisted-by: Claude:claude-opus-5
Signed-off-by: Song Liu 
Signed-off-by: Josh Poimboeuf 
Signed-off-by: Ingo Molnar 
Link: https://patch.msgid.link/20260916184351.2720310-52-song@kernel.org

objtool/klp: Add test for a static call introduced by the patch

2026-09-21T09:12:07+00:00

The counterpart to the static branch case: a patch may add a static call to
a function which had none, so the .static_call_sites entry is new and there
is nothing in the original to correlate it against.

Where the key lives still decides whether that is allowed.  A vmlinux key
is reachable; a module-owned one is not, for the same reason an existing
module key is not -- late module patching lets the livepatch load first and
the unresolved entry is dereferenced when the module arrives.  Both halves
are here because they fail in opposite directions: dropping the new entry
leaves a static call the kernel never patches, and accepting a new
module-owned one is the corruption the check exists to prevent.

Both halves are one test over one fixture: built with -DNEW_CALL the key is
vmlinux's and the new entry has to be carried in; built with -DMODNAME as
well the key belongs to a module, klp diff has to reject it, and no output
object may be left behind.  The premise is asserted first -- the original
must have no .static_call_sites at all -- since otherwise this is a second
copy of test-static-call-module-key.

Covers the same ground as corpus/x86_64/static-call-vmlinux-new and
corpus/x86_64/static-call-module-new in Joe Lawrence's klp-build unit test
corpus.

Assisted-by: Claude:claude-opus-4
Based-on-test-by: Joe Lawrence 
Assisted-by: Claude:claude-opus-5
Signed-off-by: Song Liu 
Signed-off-by: Josh Poimboeuf 
Signed-off-by: Ingo Molnar 
Link: https://patch.msgid.link/20260916184351.2720310-51-song@kernel.org

objtool/klp: Add test for tracepoint and pr_debug static branch keys

2026-09-21T09:12:07+00:00

A module-owned static branch key is normally fatal, because late module
patching lets the livepatch load before the module it depends on and
jump_label_add_module() then dereferences an unresolved entry.

Tracepoints and pr_debug() generate such keys everywhere, so refusing them
outright would make any function containing a trace_*() call or a
pr_debug() unpatchable.  klp diff drops the entry, warns, and carries on:
the patched code works with that one tracepoint or debug print permanently
off.

Both halves matter, and the test asserts both.  A build which fails is a
function nobody can patch; an entry left in place is the corruption the
rejection exists to prevent.

Give the fixture a KEY_NAME knob so the same static branch can be built
with either special name.  Verified by removing each exemption in turn --
the test fails for both.  That the entry is then dropped is asserted but
not isolated, and the test says so.

Assisted-by: Claude:claude-opus-4
Based-on-test-by: Joe Lawrence 
Assisted-by: Claude:claude-opus-5
Signed-off-by: Song Liu 
Signed-off-by: Josh Poimboeuf 
Signed-off-by: Ingo Molnar 
Link: https://patch.msgid.link/20260916184351.2720310-50-song@kernel.org

objtool/klp: Add test for a static branch introduced by the patch

2026-09-21T09:12:07+00:00

Patching a function which already has a static branch and adding one to a
function which had none are different cases.  In the second the
__jump_table entry is itself new, so there is nothing in the original to
correlate it against: klp diff has to carry the entry into the patch from
scratch and reach the key the way it reaches any other vmlinux symbol.

Dropping it is silent.  The patched function keeps a static branch the
kernel never patches, so it takes the same arm forever whatever the key is
set to.

Give the fixture a NEW_KEY knob which puts the whole branch behind PATCHED,
and assert the premise -- that the original really has no __jump_table --
before asserting the result, since otherwise this is just a second copy of
test-jump-label-key.

Verified by making klp diff skip __jump_table when cloning special
sections: the test fails.

Assisted-by: Claude:claude-opus-4
Based-on-test-by: Joe Lawrence 
Assisted-by: Claude:claude-opus-5
Signed-off-by: Song Liu 
Signed-off-by: Josh Poimboeuf 
Signed-off-by: Ingo Molnar 
Link: https://patch.msgid.link/20260916184351.2720310-49-song@kernel.org