linux/tools/objtool/Build, branch master

objtool: Add more robust signal error handling, detect and warn about stack overflows

2025-12-03T18:42:37Z

When the kernel build fails due to an objtool segfault, the error message is a bit obtuse and confusing: make[5]: *** [scripts/Makefile.build:503: drivers/scsi/qla2xxx/qla2xxx.o] Error 139 ^^^^^^^^^ make[5]: *** Deleting file 'drivers/scsi/qla2xxx/qla2xxx.o' make[4]: *** [scripts/Makefile.build:556: drivers/scsi/qla2xxx] Error 2 make[3]: *** [scripts/Makefile.build:556: drivers/scsi] Error 2 make[2]: *** [scripts/Makefile.build:556: drivers] Error 2 make[1]: *** [/home/jpoimboe/git/linux/Makefile:2013: .] Error 2 make: *** [Makefile:248: __sub-make] Error 2 Add a signal handler to objtool which prints an error message like if the local stack has overflown (for which there's a chance as objtool makes heavy use of recursion): drivers/scsi/qla2xxx/qla2xxx.o: error: SIGSEGV: objtool stack overflow! or: drivers/scsi/qla2xxx/qla2xxx.o: error: SIGSEGV: objtool crash! Also, re-raise the signal so the core dump still gets triggered. [ mingo: Applied a build fix, added more comments and prettified the code. ] Suggested-by: Ingo Molnar Signed-off-by: Josh Poimboeuf Signed-off-by: Ingo Molnar Cc: Alexandre Chartre Cc: David Laight Cc: Linus Torvalds Cc: Nathan Chancellor Cc: Peter Zijlstra Link: https://patch.msgid.link/mi4tihk4dbncn7belrhp6ooudhpw4vdggerktu5333w3gqf3uf@vqlhc3y667mg

objtool: Add option to trace function validation

2025-11-21T14:30:09Z

Add an option to trace and have information during the validation of specified functions. Functions are specified with the --trace option which can be a single function name (e.g. --trace foo to trace the function with the name "foo"), or a shell wildcard pattern (e.g. --trace foo* to trace all functions with a name starting with "foo"). Signed-off-by: Alexandre Chartre Signed-off-by: Peter Zijlstra (Intel) Acked-by: Josh Poimboeuf Link: https://patch.msgid.link/20251121095340.464045-11-alexandre.chartre@oracle.com

objtool: Disassemble code with libopcodes instead of running objdump

2025-11-21T14:30:07Z

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: Move disassembly functions to a separated file

2025-11-21T14:30:06Z

objtool disassembles functions which have warnings. Move the code to do that to a dedicated file. The code is just moved, it is not changed. Signed-off-by: Alexandre Chartre Signed-off-by: Peter Zijlstra (Intel) Acked-by: Josh Poimboeuf Link: https://patch.msgid.link/20251121095340.464045-2-alexandre.chartre@oracle.com

objtool/klp: Add post-link subcommand to finalize livepatch modules

2025-10-14T21:50:18Z

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, the .ko then needs to be converted to an actual livepatch module. Introduce a new klp post-link subcommand to do so. Acked-by: Petr Mladek Tested-by: Joe Lawrence Signed-off-by: Josh Poimboeuf

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

2025-10-14T21:50:18Z

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

objtool: Install libsubcmd in build

2023-01-31T00:27:46Z

Including from tools/lib can create inadvertent dependencies. Install libsubcmd in the objtool build and then include the headers from there. Signed-off-by: Ian Rogers Link: https://lore.kernel.org/r/20230126190606.40739-2-irogers@google.com Signed-off-by: Josh Poimboeuf

objtool: Ditch subcommands

2022-04-22T10:32:01Z

Objtool has a fairly singular focus. It runs on object files and does validations and transformations which can be combined in various ways. The subcommand model has never been a good fit, making it awkward to combine and remove options. Remove the "check" and "orc" subcommands in favor of a more traditional cmdline option model. This makes it much more flexible to use, and easier to port individual features to other arches. Signed-off-by: Josh Poimboeuf Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Miroslav Benes Link: https://lkml.kernel.org/r/5c61ebf805e90aefc5fa62bc63468ffae53b9df6.1650300597.git.jpoimboe@redhat.com

objtool: Enable compilation of objtool for all architectures

2020-05-20T14:17:28Z

Objtool currently only compiles for x86 architectures. This is fine as it presently does not support tooling for other architectures. However, we would like to be able to convert other kernel tools to run as objtool sub commands because they too process ELF object files. This will allow us to convert tools such as recordmcount to use objtool's ELF code. Since much of recordmcount's ELF code is copy-paste code to/from a variety of other kernel tools (look at modpost for example) this means that if we can convert recordmcount we can convert more. We define weak definitions for subcommand entry functions and other weak definitions for shared functions critical to building existing subcommands. These return 127 when the command is missing which signify tools that do not exist on all architectures. In this case the "check" and "orc" tools do not exist on all architectures so we only add them for x86. Future changes adding support for "check", to arm64 for example, can then modify the SUBCMD_CHECK variable when building for arm64. Objtool is not currently wired in to KConfig to be built for other architectures because it's not needed for those architectures and there are no commands it supports other than those for x86. As more command support is enabled on various architectures the necessary KConfig changes can be made (e.g. adding "STACK_VALIDATION") to trigger building objtool. [ jpoimboe: remove aliases, add __weak macro, add error messages ] Cc: Julien Thierry Signed-off-by: Matt Helsley Signed-off-by: Josh Poimboeuf

objtool: Optimize find_symbol_*() and read_symbols()

2020-03-25T17:28:29Z

All of: read_symbols(), find_symbol_by_offset(), find_symbol_containing(), find_containing_func() do a linear search of the symbols. Add an RB tree to make it go faster. This about halves objtool runtime on vmlinux.o, from 34s to 18s. Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Miroslav Benes Acked-by: Josh Poimboeuf Link: https://lkml.kernel.org/r/20200324160924.499016559@infradead.org