Changes in Build

bdb8bf7d - objtool: Install libsubcmd in build

Thu, 26 Jan 2023 19:06:04 +0000

objtool: Install libsubcmd in buildIncluding from tools/lib can create inadvertent dependencies. Installlibsubcmd in the objtool build and then include the headers fromthere.Signed-off-by: Ian Rogers Link: https://lore.kernel.org/r/20230126190606.40739-2-irogers@google.comSigned-off-by: Josh Poimboeuf List of files: /linux-6.15/tools/objtool/Build

b51277eb - objtool: Ditch subcommands

Mon, 18 Apr 2022 16:50:27 +0000

objtool: Ditch subcommandsObjtool has a fairly singular focus. It runs on object files and doesvalidations and transformations which can be combined in various ways.The subcommand model has never been a good fit, making it awkward tocombine and remove options.Remove the "check" and "orc" subcommands in favor of a more traditionalcmdline option model. This makes it much more flexible to use, andeasier 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 List of files: /linux-6.15/tools/objtool/Build

0decf1f8 - objtool: Enable compilation of objtool for all architectures

Tue, 19 May 2020 20:55:33 +0000

objtool: Enable compilation of objtool for all architecturesObjtool currently only compiles for x86 architectures. This isfine as it presently does not support tooling for otherarchitectures. However, we would like to be able to convert otherkernel tools to run as objtool sub commands because they tooprocess ELF object files. This will allow us to convert toolssuch as recordmcount to use objtool's ELF code.Since much of recordmcount's ELF code is copy-paste code to/froma variety of other kernel tools (look at modpost for example) thismeans that if we can convert recordmcount we can convert more.We define weak definitions for subcommand entry functions and other weakdefinitions for shared functions critical to building existingsubcommands. These return 127 when the command is missing which signifytools 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 themfor x86. Future changes adding support for "check", to arm64 forexample, can then modify the SUBCMD_CHECK variable when building forarm64.Objtool is not currently wired in to KConfig to be built for otherarchitectures because it's not needed for those architectures andthere are no commands it supports other than those for x86. As morecommand support is enabled on various architectures the necessaryKConfig changes can be made (e.g. adding "STACK_VALIDATION") totrigger building objtool.[ jpoimboe: remove aliases, add __weak macro, add error messages ]Cc: Julien Thierry Signed-off-by: Matt Helsley Signed-off-by: Josh Poimboeuf List of files: /linux-6.15/tools/objtool/Build

2a362ecc - objtool: Optimize find_symbol_*() and read_symbols()

Thu, 12 Mar 2020 08:34:42 +0000

objtool: Optimize find_symbol_*() and read_symbols()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 gofaster.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 List of files: /linux-6.15/tools/objtool/Build

0c69b931 - objtool: Fix build by linking against tools/lib/ctype.o sources

Tue, 02 Jul 2019 12:12:40 +0000

objtool: Fix build by linking against tools/lib/ctype.o sourcesFix objtool build, because it adds _ctype dependency via isspace call patch.Signed-off-by: Jiri Olsa Cc: Adrian Hunter Cc: André Goddard Rosa Cc: Clark Williams Cc: Jiri Olsa Cc: Namhyung Kim Cc: Thomas Gleixner Fixes: 7bd330de43fd ("tools lib: Adopt skip_spaces() from the kernel sources")Link: http://lkml.kernel.org/r/20190702121240.GB12694@kravaSigned-off-by: Arnaldo Carvalho de Melo List of files: /linux-6.15/tools/objtool/Build

627fce14 - objtool: Add ORC unwind table generation

Tue, 11 Jul 2017 15:33:42 +0000

objtool: Add ORC unwind table generationNow that objtool knows the states of all registers on the stack for eachinstruction, it's straightforward to generate debuginfo for an unwinderto use.Instead of generating DWARF, generate a new format called ORC, which ismore suitable for an in-kernel unwinder. SeeDocumentation/x86/orc-unwinder.txt for a more detailed description ofthis new debuginfo format and why it's preferable to DWARF.Signed-off-by: Josh Poimboeuf Cc: Andy Lutomirski Cc: Borislav Petkov Cc: Brian Gerst Cc: Denys Vlasenko Cc: H. Peter Anvin Cc: Jiri Slaby Cc: Linus Torvalds Cc: Mike Galbraith Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: live-patching@vger.kernel.orgLink: http://lkml.kernel.org/r/c9b9f01ba6c5ed2bdc9bb0957b78167fdbf9632e.1499786555.git.jpoimboe@redhat.comSigned-off-by: Ingo Molnar List of files: /linux-6.15/tools/objtool/Build

dcc914f4 - objtool: Move checking code to check.c

Wed, 28 Jun 2017 15:11:05 +0000

objtool: Move checking code to check.cIn preparation for the new 'objtool undwarf generate' command, whichwill rely on 'objtool check', move the checking code frombuiltin-check.c to check.c where it can be used by other commands.Signed-off-by: Josh Poimboeuf Reviewed-by: Jiri Slaby Cc: Andy Lutomirski Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: live-patching@vger.kernel.orgLink: http://lkml.kernel.org/r/294c5c695fd73c1a5000bbe5960a7c9bec4ee6b4.1498659915.git.jpoimboe@redhat.comSigned-off-by: Ingo Molnar List of files: /linux-6.15/tools/objtool/Build

60cbdf5d - tools build: Fix objtool build with ARCH=x86_64

Fri, 22 Jul 2016 19:19:20 +0000

tools build: Fix objtool build with ARCH=x86_64The objtool build fails in a cross-compiled environment on a non-x86host with "ARCH=x86_64": tools/objtool/objtool-in.o: In function `decode_instructions': tools/objtool/builtin-check.c:276: undefined reference to `arch_decode_instruction'We could override the ARCH environment variable and change it back tox86, similar to what the objtool Makefile was doing before; but it'stricky to override environment variables consistently.Instead, take a similar approach used by the Linux top-level Makefileand introduce a SRCARCH Makefile variable which evaluates to "x86" whenARCH is either "x86_64" or "x86".Reported-by: Stephen Rothwell Signed-off-by: Josh Poimboeuf Cc: Andy Lutomirski Cc: H. Peter Anvin Cc: Peter Zijlstra Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/20160722191920.ej62fnspnqurbaa7@trebleSigned-off-by: Arnaldo Carvalho de Melo List of files: /linux-6.15/tools/objtool/Build

07eebccb - tools lib subcmd: Use str_error_r()

Fri, 08 Jul 2016 18:26:50 +0000

tools lib subcmd: Use str_error_r()To make it portable to non-glibc systems, that follow the XSI variantinstead of the GNU specific one that gets in place when _GNU_SOURCE isdefined.Cc: Adrian Hunter Cc: David Ahern Cc: Jiri Olsa Cc: Josh Poimboeuf Cc: Namhyung Kim Cc: Steven Rostedt Cc: Wang Nan Link: http://lkml.kernel.org/n/tip-bozcszy93tpgw9ad6qm3dhpx@git.kernel.orgSigned-off-by: Arnaldo Carvalho de Melo List of files: /linux-6.15/tools/objtool/Build

442f04c3 - objtool: Add tool to perform compile-time stack metadata validation

Mon, 29 Feb 2016 04:22:41 +0000

objtool: Add tool to perform compile-time stack metadata validationThis adds a host tool named objtool which has a "check" subcommand whichanalyzes .o files to ensure the validity of stack metadata. It enforcesa set of rules on asm code and C inline assembly code so that stacktraces can be reliable.For each function, it recursively follows all possible code paths andvalidates the correct frame pointer state at each instruction.It also follows code paths involving kernel special sections, like.altinstructions, __jump_table, and __ex_table, which can addalternative execution paths to a given instruction (or set ofinstructions). Similarly, it knows how to follow switch statements, forwhich gcc sometimes uses jump tables.Here are some of the benefits of validating stack metadata:a) More reliable stack traces for frame pointer enabled kernels Frame pointers are used for debugging purposes. They allow runtime code and debug tools to be able to walk the stack to determine the chain of function call sites that led to the currently executing code. For some architectures, frame pointers are enabled by CONFIG_FRAME_POINTER. For some other architectures they may be required by the ABI (sometimes referred to as "backchain pointers"). For C code, gcc automatically generates instructions for setting up frame pointers when the -fno-omit-frame-pointer option is used. But for asm code, the frame setup instructions have to be written by hand, which most people don't do. So the end result is that CONFIG_FRAME_POINTER is honored for C code but not for most asm code. For stack traces based on frame pointers to be reliable, all functions which call other functions must first create a stack frame and update the frame pointer. If a first function doesn't properly create a stack frame before calling a second function, the *caller* of the first function will be skipped on the stack trace. For example, consider the following example backtrace with frame pointers enabled: [] dump_stack+0x4b/0x63 [] cmdline_proc_show+0x12/0x30 [] seq_read+0x108/0x3e0 [] proc_reg_read+0x42/0x70 [] __vfs_read+0x37/0x100 [] vfs_read+0x86/0x130 [] SyS_read+0x58/0xd0 [] entry_SYSCALL_64_fastpath+0x12/0x76 It correctly shows that the caller of cmdline_proc_show() is seq_read(). If we remove the frame pointer logic from cmdline_proc_show() by replacing the frame pointer related instructions with nops, here's what it looks like instead: [] dump_stack+0x4b/0x63 [] cmdline_proc_show+0x12/0x30 [] proc_reg_read+0x42/0x70 [] __vfs_read+0x37/0x100 [] vfs_read+0x86/0x130 [] SyS_read+0x58/0xd0 [] entry_SYSCALL_64_fastpath+0x12/0x76 Notice that cmdline_proc_show()'s caller, seq_read(), has been skipped. Instead the stack trace seems to show that cmdline_proc_show() was called by proc_reg_read(). The benefit of "objtool check" here is that because it ensures that *all* functions honor CONFIG_FRAME_POINTER, no functions will ever[*] be skipped on a stack trace. [*] unless an interrupt or exception has occurred at the very beginning of a function before the stack frame has been created, or at the very end of the function after the stack frame has been destroyed. This is an inherent limitation of frame pointers.b) 100% reliable stack traces for DWARF enabled kernels This is not yet implemented. For more details about what is planned, see tools/objtool/Documentation/stack-validation.txt.c) Higher live patching compatibility rate This is not yet implemented. For more details about what is planned, see tools/objtool/Documentation/stack-validation.txt.To achieve the validation, "objtool check" enforces the following rules:1. Each callable function must be annotated as such with the ELF function type. In asm code, this is typically done using the ENTRY/ENDPROC macros. If objtool finds a return instruction outside of a function, it flags an error since that usually indicates callable code which should be annotated accordingly. This rule is needed so that objtool can properly identify each callable function in order to analyze its stack metadata.2. Conversely, each section of code which is *not* callable should *not* be annotated as an ELF function. The ENDPROC macro shouldn't be used in this case. This rule is needed so that objtool can ignore non-callable code. Such code doesn't have to follow any of the other rules.3. Each callable function which calls another function must have the correct frame pointer logic, if required by CONFIG_FRAME_POINTER or the architecture's back chain rules. This can by done in asm code with the FRAME_BEGIN/FRAME_END macros. This rule ensures that frame pointer based stack traces will work as designed. If function A doesn't create a stack frame before calling function B, the _caller_ of function A will be skipped on the stack trace.4. Dynamic jumps and jumps to undefined symbols are only allowed if: a) the jump is part of a switch statement; or b) the jump matches sibling call semantics and the frame pointer has the same value it had on function entry. This rule is needed so that objtool can reliably analyze all of a function's code paths. If a function jumps to code in another file, and it's not a sibling call, objtool has no way to follow the jump because it only analyzes a single file at a time.5. A callable function may not execute kernel entry/exit instructions. The only code which needs such instructions is kernel entry code, which shouldn't be be in callable functions anyway. This rule is just a sanity check to ensure that callable functions return normally.It currently only supports x86_64. I tried to make the code generic sothat support for other architectures can hopefully be plugged inrelatively easily.On my Lenovo laptop with a i7-4810MQ 4-core/8-thread CPU, building thekernel with objtool checking every .o file adds about three seconds oftotal build time. It hasn't been optimized for performance yet, sothere are probably some opportunities for better build performance.Signed-off-by: Josh Poimboeuf Cc: Andrew Morton Cc: Andy Lutomirski Cc: Arnaldo Carvalho de Melo Cc: Bernd Petrovitsch Cc: Borislav Petkov Cc: Chris J Arges Cc: Jiri Slaby Cc: Linus Torvalds Cc: Michal Marek Cc: Namhyung Kim Cc: Pedro Alves Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: live-patching@vger.kernel.orgLink: http://lkml.kernel.org/r/f3efb173de43bd067b060de73f856567c0fa1174.1456719558.git.jpoimboe@redhat.comSigned-off-by: Ingo Molnar List of files: /linux-6.15/tools/objtool/Build