kernel/linux.git/tools/objtool/Makefile, branch v6.19.11

objtool: Use HOSTCFLAGS for HAVE_XXHASH test

2026-04-02T11:25:20+00:00

[ Upstream commit 32234049107d012703d50547e815f198f147968b ] Previously, HAVE_XXHASH is tested by invoking HOSTCC without HOSTCFLAGS. Consider the following scenario: - The host machine has libxxhash installed - We build the kernel with HOSTCFLAGS containing a --sysroot that does not have xxhash.h (for hermetic builds) In this case, HAVE_XXHASH is set to y, but when it builds objtool with HOSTCFLAGS, because the --sysroot does not contain xxhash.h, the following error is raised: <...>/common/tools/objtool/include/objtool/checksum_types.h:12:10: fatal error: 'xxhash.h' file not found 12 | #include | ^~~~~~~~~~ To resolve the error, we test HAVE_XXHASH by invoking HOSTCC with HOSTCFLAGS. Signed-off-by: HONG Yifan Reviewed-by: Carlos Llamas Link: https://patch.msgid.link/20260303010340.306164-1-elsk@google.com Signed-off-by: Josh Poimboeuf Signed-off-by: Sasha Levin

kbuild: Leave objtool binary around with 'make clean'

2026-03-12T11:09:39+00:00

commit fdb12c8a24a453bdd6759979b6ef1e04ebd4beb4 upstream. The difference between 'make clean' and 'make mrproper' is documented in 'make help' as: clean - Remove most generated files but keep the config and enough build support to build external modules mrproper - Remove all generated files + config + various backup files After commit 68b4fe32d737 ("kbuild: Add objtool to top-level clean target"), running 'make clean' then attempting to build an external module with the resulting build directory fails with $ make ARCH=x86_64 O=build clean $ make -C build M=... MO=... ... /bin/sh: line 1: .../build/tools/objtool/objtool: No such file or directory as 'make clean' removes the objtool binary. Split the objtool clean target into mrproper and clean like Kbuild does and remove all generated artifacts with 'make clean' except for the objtool binary, which is removed with 'make mrproper'. To avoid a small race when running the objtool clean target through both objtool_mrproper and objtool_clean when running 'make mrproper', modify objtool's clean up find command to avoid using find's '-delete' command by piping the files into 'xargs rm -f' like the rest of Kbuild does. Cc: stable@vger.kernel.org Fixes: 68b4fe32d737 ("kbuild: Add objtool to top-level clean target") Reported-by: Michal Suchanek Closes: https://lore.kernel.org/20260225112633.6123-1-msuchanek@suse.de/ Reported-by: Rainer Fiebig Closes: https://lore.kernel.org/62d12399-76e5-3d40-126a-7490b4795b17@mailbox.org/ Acked-by: Josh Poimboeuf Acked-by: Peter Zijlstra (Intel) Reviewed-by: Nicolas Schier Tested-by: Nicolas Schier Link: https://patch.msgid.link/20260227-avoid-objtool-binary-removal-clean-v1-1-122f3e55eae9@kernel.org Signed-off-by: Nathan Chancellor Signed-off-by: Greg Kroah-Hartman

kbuild: Add objtool to top-level clean target

2026-02-26T23:01:28+00:00

[ Upstream commit 68b4fe32d73789dea23e356f468de67c8367ef8f ] Objtool is an integral part of the build, make sure it gets cleaned by "make clean" and "make mrproper". Fixes: 442f04c34a1a ("objtool: Add tool to perform compile-time stack metadata validation") Reported-by: Jens Remus Closes: https://lore.kernel.org/15f2af3b-be33-46fc-b972-6b8e7e0aa52e@linux.ibm.com Signed-off-by: Josh Poimboeuf Tested-by: Jens Remus Link: https://patch.msgid.link/968faf2ed30fa8b3519f79f01a1ecfe7929553e5.1770759919.git.jpoimboe@kernel.org [nathan: use Closes: instead of Link: per checkpatch.pl] Signed-off-by: Nathan Chancellor Signed-off-by: Sasha Levin

objtool: Fix libopcodes linking with static libraries

2026-01-21T19:25:14+00:00

Commit 436326bc525d ("objtool: fix build failure due to missing libopcodes check") tests for libopcodes using an empty main(), which passes even when static libraries lack their dependencies. This causes undefined reference errors (xmalloc, bfd_get_bits, etc.) when linking against static libopcodes without its required libbfd and libiberty. Fix by testing with an actual libopcodes symbol and trying increasingly complete library combinations until one succeeds. Fixes: 436326bc525d ("objtool: fix build failure due to missing libopcodes check") Reported-by: Rafael J. Wysocki Signed-off-by: Sasha Levin Signed-off-by: Peter Zijlstra (Intel) Tested-by: Rafael J. Wysocki (Intel) Link: https://patch.msgid.link/20260121162532.1596238-1-sashal@kernel.org

objtool: fix build failure due to missing libopcodes check

2026-01-13T10:37:51+00:00

Commit 59953303827e ("objtool: Disassemble code with libopcodes instead of running objdump") added support for using libopcodes for disassembly. However, the feature detection checks for libbfd availability but then unconditionally links against libopcodes: ifeq ($(feature-libbfd),1) OBJTOOL_LDFLAGS += -lopcodes endif This causes build failures in environments where libbfd is installed but libopcodes is not, since the test-libbfd.c feature test only links against -lbfd and -ldl, not -lopcodes: /usr/bin/ld: cannot find -lopcodes: No such file or directory collect2: error: ld returned 1 exit status make[4]: *** [Makefile:109: objtool] Error 1 Additionally, the shared feature framework uses $(CC) which is the cross-compiler in cross-compilation builds. Since objtool is a host tool that links with $(HOSTCC) against host libraries, the feature detection can falsely report libopcodes as available when the cross-compiler's sysroot has it but the host system doesn't. Fix this by replacing the feature framework check with a direct inline test that uses $(HOSTCC) to compile and link a test program against libopcodes, similar to how xxhash availability is detected. Fixes: 59953303827e ("objtool: Disassemble code with libopcodes instead of running objdump") Assisted-by: claude-opus-4-5-20251101 Signed-off-by: Sasha Levin Signed-off-by: Peter Zijlstra (Intel) Link: https://patch.msgid.link/20251223120357.2492008-1-sashal@kernel.org

objtool: Build with disassembly can fail when including bdf.h

2025-11-27T08:32:46+00:00

Building objtool with disassembly support can fail when including the bdf.h file: In file included from tools/objtool/include/objtool/arch.h:108, from check.c:14: /usr/include/bfd.h:35:2: error: #error config.h must be included before this header 35 | #error config.h must be included before this header | ^~~~~ This check is present in the bfd.h file generated from the binutils source code, but it is not necessarily present in the bfd.h file provided in a binutil package (for example, it is not present in the binutil RPM). The solution to this issue is to define the PACKAGE macro before including bfd.h. This is the solution suggested by the binutil developer in bug 14243, and it is used by other kernel tools which also use bfd.h (perf and bpf). Fixes: 59953303827ec ("objtool: Disassemble code with libopcodes instead of running objdump") Closes: https://lore.kernel.org/all/3fa261fd-3b46-4cbe-b48d-7503aabc96cb@oracle.com/ Reported-by: Nathan Chancellor Suggested-by: Nathan Chancellor Signed-off-by: Alexandre Chartre Signed-off-by: Peter Zijlstra (Intel) Link: https://sourceware.org/bugzilla/show_bug.cgi?id=14243 Link: https://patch.msgid.link/20251126134519.1760889-1-alexandre.chartre@oracle.com

objtool: Add Function to get the name of a CPU feature

2025-11-24T19:39:47+00:00

Add a function to get the name of a CPU feature. The function is architecture dependent and currently only implemented for x86. The feature names are automatically generated from the cpufeatures.h include file. Signed-off-by: Alexandre Chartre Signed-off-by: Peter Zijlstra (Intel) Acked-by: Josh Poimboeuf Link: https://patch.msgid.link/20251121095340.464045-27-alexandre.chartre@oracle.com

objtool: Disassemble code with libopcodes instead of running objdump

2025-11-21T14:30:07+00:00

objtool executes the objdump command to disassemble code. Use libopcodes instead to have more control about the disassembly scope and output. If libopcodes is not present then objtool is built without disassembly support. Signed-off-by: Alexandre Chartre Signed-off-by: Peter Zijlstra (Intel) Acked-by: Josh Poimboeuf Link: https://patch.msgid.link/20251121095340.464045-4-alexandre.chartre@oracle.com

objtool: Set minimum xxhash version to 0.8

2025-11-18T08:59:25+00:00

XXH3 is only supported starting with xxhash 0.8. Enforce that. Fixes: 0d83da43b1e1 ("objtool/klp: Add --checksum option to generate per-function checksums") Closes: https://lore.kernel.org/SN6PR02MB41579B83CD295C9FEE40EED6D4FCA@SN6PR02MB4157.namprd02.prod.outlook.com Reported-by: Michael Kelley Signed-off-by: Josh Poimboeuf Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Michael Kelley Tested-by: Michael Kelley Link: https://patch.msgid.link/7227c94692a3a51840278744c7af31b4797c6b96.1762990139.git.jpoimboe@kernel.org

objtool/klp: Introduce klp diff subcommand for diffing object files

2025-10-14T21:50:18+00:00

Add a new klp diff subcommand which performs a binary diff between two object files and extracts changed functions into a new object which can then be linked into a livepatch module. This builds on concepts from the longstanding out-of-tree kpatch [1] project which began in 2012 and has been used for many years to generate livepatch modules for production kernels. However, this is a complete rewrite which incorporates hard-earned lessons from 12+ years of maintaining kpatch. Key improvements compared to kpatch-build: - Integrated with objtool: Leverages objtool's existing control-flow graph analysis to help detect changed functions. - Works on vmlinux.o: Supports late-linked objects, making it compatible with LTO, IBT, and similar. - Simplified code base: ~3k fewer lines of code. - Upstream: No more out-of-tree #ifdef hacks, far less cruft. - Cleaner internals: Vastly simplified logic for symbol/section/reloc inclusion and special section extraction. - Robust __LINE__ macro handling: Avoids false positive binary diffs caused by the __LINE__ macro by introducing a fix-patch-lines script (coming in a later patch) which injects #line directives into the source .patch to preserve the original line numbers at compile time. Note the end result of this subcommand is not yet functionally complete. Livepatch needs some ELF magic which linkers don't like: - Two relocation sections (.rela*, .klp.rela*) for the same text section. - Use of SHN_LIVEPATCH to mark livepatch symbols. Unfortunately linkers tend to mangle such things. To work around that, klp diff generates a linker-compliant intermediate binary which encodes the relevant KLP section/reloc/symbol metadata. After module linking, a klp post-link step (coming soon) will clean up the mess and convert the linked .ko into a fully compliant livepatch module. Note this subcommand requires the diffed binaries to have been compiled with -ffunction-sections and -fdata-sections, and processed with 'objtool --checksum'. Those constraints will be handled by a klp-build script introduced in a later patch. Without '-ffunction-sections -fdata-sections', reliable object diffing would be infeasible due to toolchain limitations: - For intra-file+intra-section references, the compiler might occasionally generated hard-coded instruction offsets instead of relocations. - Section-symbol-based references can be ambiguous: - Overlapping or zero-length symbols create ambiguity as to which symbol is being referenced. - A reference to the end of a symbol (e.g., checking array bounds) can be misinterpreted as a reference to the next symbol, or vice versa. A potential future alternative to '-ffunction-sections -fdata-sections' would be to introduce a toolchain option that forces symbol-based (non-section) relocations. Acked-by: Petr Mladek Tested-by: Joe Lawrence Signed-off-by: Josh Poimboeuf