Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33, v6.1.32, v6.1.31, v6.1.30, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22, v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9 |
|
#
cd955bdd |
| 26-Jan-2023 |
Ian Rogers <irogers@google.com> |
objtool: Fix HOSTCC flag usage
HOSTCC is always wanted when building objtool. Setting CC to HOSTCC happens after tools/scripts/Makefile.include is included, meaning flags (like CFLAGS) are set assum
objtool: Fix HOSTCC flag usage
HOSTCC is always wanted when building objtool. Setting CC to HOSTCC happens after tools/scripts/Makefile.include is included, meaning flags (like CFLAGS) are set assuming say CC is gcc, but then it can be later set to HOSTCC which may be clang. tools/scripts/Makefile.include is needed for host set up and common macros in objtool's Makefile. Rather than override the CC variable to HOSTCC, just pass CC as HOSTCC to the sub-makes of Makefile.build, the libsubcmd builds and also to the linkage step.
Signed-off-by: Ian Rogers <irogers@google.com> Link: https://lore.kernel.org/r/20230126190606.40739-4-irogers@google.com Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
show more ...
|
#
8c4526ca |
| 26-Jan-2023 |
Ian Rogers <irogers@google.com> |
objtool: Properly support make V=1
The Q variable was being used but never correctly set up. Add the setting up and use in place of @.
Signed-off-by: Ian Rogers <irogers@google.com> Link: https://l
objtool: Properly support make V=1
The Q variable was being used but never correctly set up. Add the setting up and use in place of @.
Signed-off-by: Ian Rogers <irogers@google.com> Link: https://lore.kernel.org/r/20230126190606.40739-3-irogers@google.com Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
show more ...
|
#
bdb8bf7d |
| 26-Jan-2023 |
Ian Rogers <irogers@google.com> |
objtool: Install libsubcmd in build
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
objtool: Install libsubcmd in build
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 <irogers@google.com> Link: https://lore.kernel.org/r/20230126190606.40739-2-irogers@google.com Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org>
show more ...
|
Revision tags: v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70, v5.15.69, v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39 |
|
#
4bc78005 |
| 11-May-2022 |
Tiezhu Yang <yangtiezhu@loongson.cn> |
objtool: Remove libsubcmd.a when make clean
The file libsubcmd.a still exists after make clean, remove it.
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn> Signed-off-by: Josh Poimboeuf <jpoimbo
objtool: Remove libsubcmd.a when make clean
The file libsubcmd.a still exists after make clean, remove it.
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn> Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org> Link: https://lore.kernel.org/r/1652258270-6278-3-git-send-email-yangtiezhu@loongson.cn
show more ...
|
#
f193c32c |
| 11-May-2022 |
Tiezhu Yang <yangtiezhu@loongson.cn> |
objtool: Remove inat-tables.c when make clean
When build objtool on x86, the generated file inat-tables.c is in arch/x86/lib instead of arch/x86, use the correct dir to remove it when make clean.
$
objtool: Remove inat-tables.c when make clean
When build objtool on x86, the generated file inat-tables.c is in arch/x86/lib instead of arch/x86, use the correct dir to remove it when make clean.
$ cd tools/objtool $ make [...] GEN arch/x86/lib/inat-tables.c [...]
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn> Signed-off-by: Josh Poimboeuf <jpoimboe@kernel.org> Link: https://lore.kernel.org/r/1652258270-6278-2-git-send-email-yangtiezhu@loongson.cn
show more ...
|
Revision tags: v5.15.38, v5.15.37, v5.15.36, v5.15.35 |
|
#
b51277eb |
| 18-Apr-2022 |
Josh Poimboeuf <jpoimboe@redhat.com> |
objtool: Ditch subcommands
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 neve
objtool: Ditch subcommands
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 <jpoimboe@redhat.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Miroslav Benes <mbenes@suse.cz> Link: https://lkml.kernel.org/r/5c61ebf805e90aefc5fa62bc63468ffae53b9df6.1650300597.git.jpoimboe@redhat.com
show more ...
|
Revision tags: v5.15.34, v5.15.33 |
|
#
d5ea4fec |
| 01-Apr-2022 |
Chun-Tse Shao <ctshao@google.com> |
kbuild: Allow kernel installation packaging to override pkg-config
Add HOSTPKG_CONFIG to allow tooling that builds the kernel to override what pkg-config and parameters are used.
Signed-off-by: Chu
kbuild: Allow kernel installation packaging to override pkg-config
Add HOSTPKG_CONFIG to allow tooling that builds the kernel to override what pkg-config and parameters are used.
Signed-off-by: Chun-Tse Shao <ctshao@google.com> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
show more ...
|
Revision tags: v5.15.32, v5.15.31, v5.17, v5.15.30, v5.15.29, v5.15.28, v5.15.27, v5.15.26, v5.15.25, v5.15.24, v5.15.23 |
|
#
5c816641 |
| 10-Feb-2022 |
Masahiro Yamada <masahiroy@kernel.org> |
kbuild: replace $(if A,A,B) with $(or A,B)
$(or ...) is available since GNU Make 3.81, and useful to shorten the code in some places.
Covert as follows:
$(if A,A,B) --> $(or A,B)
This patch a
kbuild: replace $(if A,A,B) with $(or A,B)
$(or ...) is available since GNU Make 3.81, and useful to shorten the code in some places.
Covert as follows:
$(if A,A,B) --> $(or A,B)
This patch also converts:
$(if A, A, B) --> $(or A, B)
Strictly speaking, the latter is not an equivalent conversion because GNU Make keeps spaces after commas; if A is not empty, $(if A, A, B) expands to " A", while $(or A, B) expands to "A".
Anyway, preceding spaces are not significant in the code hunks I touched.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
show more ...
|
Revision tags: v5.15.22, v5.15.21, v5.15.20, v5.15.19, v5.15.18, v5.15.17, v5.4.173, v5.15.16, v5.15.15, v5.16, v5.15.10, v5.15.9, v5.15.8, v5.15.7, v5.15.6, v5.15.5, v5.15.4, v5.15.3, v5.15.2, v5.15.1, v5.15, v5.14.14, v5.14.13, v5.14.12, v5.14.11, v5.14.10, v5.14.9, v5.14.8, v5.14.7, v5.14.6, v5.10.67, v5.10.66, v5.14.5, v5.14.4, v5.10.65, v5.14.3, v5.10.64, v5.14.2, v5.10.63, v5.14.1, v5.10.62, v5.14, v5.10.61, v5.10.60, v5.10.53, v5.10.52, v5.10.51, v5.10.50, v5.10.49, v5.13, v5.10.46, v5.10.43, v5.10.42, v5.10.41, v5.10.40, v5.10.39, v5.4.119, v5.10.36, v5.10.35, v5.10.34, v5.4.116, v5.10.33, v5.12, v5.10.32, v5.10.31, v5.10.30, v5.10.27, v5.10.26, v5.10.25, v5.10.24, v5.10.23, v5.10.22, v5.10.21, v5.10.20, v5.10.19, v5.4.101, v5.10.18, v5.10.17, v5.11, v5.10.16, v5.10.15, v5.10.14 |
|
#
ab4e0744 |
| 17-Dec-2020 |
Josh Poimboeuf <jpoimboe@redhat.com> |
objtool: Refactor ORC section generation
Decouple ORC entries from instructions. This simplifies the control/data flow, and is going to make it easier to support alternative instructions which chan
objtool: Refactor ORC section generation
Decouple ORC entries from instructions. This simplifies the control/data flow, and is going to make it easier to support alternative instructions which change the stack layout.
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
show more ...
|
Revision tags: v5.10 |
|
#
7786032e |
| 12-Nov-2020 |
Vasily Gorbik <gor@linux.ibm.com> |
objtool: Rework header include paths
Currently objtool headers are being included either by their base name or included via ../ from a parent directory. In case of a base name usage:
#include "war
objtool: Rework header include paths
Currently objtool headers are being included either by their base name or included via ../ from a parent directory. In case of a base name usage:
#include "warn.h" #include "arch_elf.h"
it does not make it apparent from which directory the file comes from. To make it slightly better, and actually to avoid name clashes some arch specific files have "arch_" suffix. And files from an arch folder have to revert to including via ../ e.g: #include "../../elf.h"
With additional architectures support and the code base growth there is a need for clearer headers naming scheme for multiple reasons: 1. to make it instantly obvious where these files come from (objtool itself / objtool arch|generic folders / some other external files), 2. to avoid name clashes of objtool arch specific headers, potential obtool arch generic headers and the system header files (there is /usr/include/elf.h already), 3. to avoid ../ includes and improve code readability. 4. to give a warm fuzzy feeling to developers who are mostly kernel developers and are accustomed to linux kernel headers arranging scheme.
Doesn't this make it instantly obvious where are these files come from?
#include <objtool/warn.h> #include <arch/elf.h>
And doesn't it look nicer to avoid ugly ../ includes? Which also guarantees this is elf.h from the objtool and not /usr/include/elf.h.
#include <objtool/elf.h>
This patch defines and implements new objtool headers arranging scheme. Which is: - all generic headers go to include/objtool (similar to include/linux) - all arch headers go to arch/$(SRCARCH)/include/arch (to get arch prefix). This is similar to linux arch specific "asm/*" headers but we are not abusing "asm" name and calling it what it is. This also helps to prevent name clashes (arch is not used in system headers or kernel exports).
To bring objtool to this state the following things are done: 1. current top level tools/objtool/ headers are moved into include/objtool/ subdirectory, 2. arch specific headers, currently only arch/x86/include/ are moved into arch/x86/include/arch/ and were stripped of "arch_" suffix, 3. new -I$(srctree)/tools/objtool/include include path to make includes like <objtool/warn.h> possible, 4. rewriting file includes, 5. make git not to ignore include/objtool/ subdirectory.
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Masami Hiramatsu <mhiramat@kernel.org> Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
show more ...
|
#
c8a950d0 |
| 10-Nov-2020 |
Jean-Philippe Brucker <jean-philippe@linaro.org> |
tools: Factor HOSTCC, HOSTLD, HOSTAR definitions
Several Makefiles in tools/ need to define the host toolchain variables. Move their definition to tools/scripts/Makefile.include
Signed-off-by: Jean
tools: Factor HOSTCC, HOSTLD, HOSTAR definitions
Several Makefiles in tools/ need to define the host toolchain variables. Move their definition to tools/scripts/Makefile.include
Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Acked-by: Jiri Olsa <jolsa@redhat.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://lore.kernel.org/bpf/20201110164310.2600671-2-jean-philippe@linaro.org
show more ...
|
#
cb14bbbb |
| 10-Nov-2020 |
Jean-Philippe Brucker <jean-philippe@linaro.org> |
tools: Factor HOSTCC, HOSTLD, HOSTAR definitions
commit c8a950d0d3b926a02c7b2e713850d38217cec3d1 upstream.
Several Makefiles in tools/ need to define the host toolchain variables. Move their defini
tools: Factor HOSTCC, HOSTLD, HOSTAR definitions
commit c8a950d0d3b926a02c7b2e713850d38217cec3d1 upstream.
Several Makefiles in tools/ need to define the host toolchain variables. Move their definition to tools/scripts/Makefile.include
Signed-off-by: Jean-Philippe Brucker <jean-philippe@linaro.org> Signed-off-by: Andrii Nakryiko <andrii@kernel.org> Acked-by: Jiri Olsa <jolsa@redhat.com> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Link: https://lore.kernel.org/bpf/20201110164310.2600671-2-jean-philippe@linaro.org Cc: Alistair Delva <adelva@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v5.8.17, v5.8.16, v5.8.15, v5.9, v5.8.14 |
|
#
2486baae |
| 05-Oct-2020 |
Vasily Gorbik <gor@linux.ibm.com> |
objtool: Allow nested externs to enable BUILD_BUG()
Currently BUILD_BUG() macro is expanded to smth like the following: do { extern void __compiletime_assert_0(void)
objtool: Allow nested externs to enable BUILD_BUG()
Currently BUILD_BUG() macro is expanded to smth like the following: do { extern void __compiletime_assert_0(void) __attribute__((error("BUILD_BUG failed"))); if (!(!(1))) __compiletime_assert_0(); } while (0);
If used in a function body this obviously would produce build errors with -Wnested-externs and -Werror.
Build objtool with -Wno-nested-externs to enable BUILD_BUG() usage.
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
show more ...
|
Revision tags: v5.8.13, v5.8.12, v5.8.11, v5.8.10, v5.8.9, v5.8.8, v5.8.7, v5.8.6, v5.4.62, v5.8.5, v5.8.4, v5.4.61 |
|
#
66734e32 |
| 25-Aug-2020 |
Julien Thierry <jthierry@redhat.com> |
objtool: Define 'struct orc_entry' only when needed
Implementation of ORC requires some definitions that are currently provided by the target architecture headers. Do not depend on these definitions
objtool: Define 'struct orc_entry' only when needed
Implementation of ORC requires some definitions that are currently provided by the target architecture headers. Do not depend on these definitions when the orc subcommand is not implemented.
This avoid requiring arches with no orc implementation to provide dummy orc definitions.
Signed-off-by: Julien Thierry <jthierry@redhat.com> Reviewed-by: Miroslav Benes <mbenes@suse.cz> Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
show more ...
|
Revision tags: v5.8.3, v5.4.60, v5.8.2, v5.4.59, v5.8.1, v5.4.58, v5.4.57, v5.4.56, v5.8, v5.7.12, v5.4.55, v5.7.11, v5.4.54, v5.7.10, v5.4.53, v5.4.52, v5.7.9, v5.7.8, v5.4.51, v5.4.50, v5.7.7, v5.4.49, v5.7.6, v5.7.5, v5.4.48, v5.7.4, v5.7.3, v5.4.47, v5.4.46, v5.7.2, v5.4.45, v5.7.1, v5.4.44, v5.7, v5.4.43, v5.4.42 |
|
#
0decf1f8 |
| 19-May-2020 |
Matt Helsley <mhelsley@vmware.com> |
objtool: Enable compilation of objtool for all architectures
Objtool currently only compiles for x86 architectures. This is fine as it presently does not support tooling for other architectures. How
objtool: Enable compilation of objtool for all architectures
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 <jthierry@redhat.com> Signed-off-by: Matt Helsley <mhelsley@vmware.com> Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
show more ...
|
Revision tags: v5.4.41, v5.4.40, v5.4.39, v5.4.38, v5.4.37, v5.4.36, v5.4.35, v5.4.34, v5.4.33, v5.4.32, v5.4.31, v5.4.30, v5.4.29, v5.6 |
|
#
6f8ca676 |
| 27-Mar-2020 |
Julien Thierry <jthierry@redhat.com> |
objtool: Split out arch-specific CFI definitions
Some CFI definitions used by generic objtool code have no reason to vary from one architecture to another. Keep those definitions in generic code an
objtool: Split out arch-specific CFI definitions
Some CFI definitions used by generic objtool code have no reason to vary from one architecture to another. Keep those definitions in generic code and move the arch-specific ones to a new arch-specific header.
Signed-off-by: Julien Thierry <jthierry@redhat.com> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Miroslav Benes <mbenes@suse.cz> Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com> Signed-off-by: Ingo Molnar <mingo@kernel.org>
show more ...
|
#
aa584727 |
| 27-Mar-2020 |
Julien Thierry <jthierry@redhat.com> |
objtool: Always do header sync check
Currently, the check of tools files against kernel equivalent is only done after every object file has been built. This means one might fix build issues against
objtool: Always do header sync check
Currently, the check of tools files against kernel equivalent is only done after every object file has been built. This means one might fix build issues against outdated headers without seeing a warning about this.
Check headers before any object is built. Also, make it part of a FORCE'd recipe so every attempt to build objtool will report the outdated headers (if any).
Signed-off-by: Julien Thierry <jthierry@redhat.com> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Miroslav Benes <mbenes@suse.cz> Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com> Signed-off-by: Ingo Molnar <mingo@kernel.org>
show more ...
|
#
a0d1c951 |
| 07-Apr-2020 |
Masahiro Yamada <masahiroy@kernel.org> |
kbuild: support LLVM=1 to switch the default tools to Clang/LLVM
As Documentation/kbuild/llvm.rst implies, building the kernel with a full set of LLVM tools gets very verbose and unwieldy.
Provide
kbuild: support LLVM=1 to switch the default tools to Clang/LLVM
As Documentation/kbuild/llvm.rst implies, building the kernel with a full set of LLVM tools gets very verbose and unwieldy.
Provide a single switch LLVM=1 to use Clang and LLVM tools instead of GCC and Binutils. You can pass it from the command line or as an environment variable.
Please note LLVM=1 does not turn on the integrated assembler. You need to pass LLVM_IAS=1 to use it. When the upstream kernel is ready for the integrated assembler, I think we can make it default.
We discussed what we need, and we agreed to go with a simple boolean flag that switches both target and host tools:
https://lkml.org/lkml/2020/3/28/494 https://lkml.org/lkml/2020/4/3/43
Some items discussed, but not adopted:
- LLVM_DIR
When multiple versions of LLVM are installed, I just thought supporting LLVM_DIR=/path/to/my/llvm/bin/ might be useful.
CC = $(LLVM_DIR)clang LD = $(LLVM_DIR)ld.lld ...
However, we can handle this by modifying PATH. So, we decided to not do this.
- LLVM_SUFFIX
Some distributions (e.g. Debian) package specific versions of LLVM with naming conventions that use the version as a suffix.
CC = clang$(LLVM_SUFFIX) LD = ld.lld(LLVM_SUFFIX) ...
will allow a user to pass LLVM_SUFFIX=-11 to use clang-11 etc., but the suffixed versions in /usr/bin/ are symlinks to binaries in /usr/lib/llvm-#/bin/, so this can also be handled by PATH.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Tested-by: Nathan Chancellor <natechancellor@gmail.com> # build Tested-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
show more ...
|
Revision tags: v5.4.28, v5.4.27, v5.4.26, v5.4.25, v5.4.24, v5.4.23, v5.4.22, v5.4.21, v5.4.20, v5.4.19, v5.4.18, v5.4.17, v5.4.16, v5.5, v5.4.15, v5.4.14 |
|
#
8580bed7 |
| 20-Jan-2020 |
Shile Zhang <shile.zhang@linux.alibaba.com> |
objtool: Fix ARCH=x86_64 build error
Building objtool with ARCH=x86_64 fails with:
$make ARCH=x86_64 -C tools/objtool ... CC arch/x86/decode.o arch/x86/decode.c:10:22: fatal err
objtool: Fix ARCH=x86_64 build error
Building objtool with ARCH=x86_64 fails with:
$make ARCH=x86_64 -C tools/objtool ... CC arch/x86/decode.o arch/x86/decode.c:10:22: fatal error: asm/insn.h: No such file or directory #include <asm/insn.h> ^ compilation terminated. mv: cannot stat ‘arch/x86/.decode.o.tmp’: No such file or directory make[2]: *** [arch/x86/decode.o] Error 1 ...
The root cause is that the command-line variable 'ARCH' cannot be overridden. It can be replaced by 'SRCARCH', which is defined in 'tools/scripts/Makefile.arch'.
Signed-off-by: Shile Zhang <shile.zhang@linux.alibaba.com> Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com> Signed-off-by: Ingo Molnar <mingo@kernel.org> Reviewed-by: Kamalesh Babulal <kamalesh@linux.vnet.ibm.com> Link: https://lore.kernel.org/r/d5d11370ae116df6c653493acd300ec3d7f5e925.1579543924.git.jpoimboe@redhat.com
show more ...
|
Revision tags: v5.4.13, v5.4.12, v5.4.11, v5.4.10, v5.4.9, v5.4.8, v5.4.7, v5.4.6, v5.4.5, v5.4.4, v5.4.3, v5.3.15, v5.4.2, v5.4.1, v5.3.14, v5.4, v5.3.13, v5.3.12, v5.3.11, v5.3.10, v5.3.9, v5.3.8, v5.3.7, v5.3.6, v5.3.5, v5.3.4, v5.3.3, v5.3.2, v5.3.1, v5.3, v5.2.14, v5.3-rc8, v5.2.13, v5.2.12 |
|
#
f73b3cc3 |
| 29-Aug-2019 |
Josh Poimboeuf <jpoimboe@redhat.com> |
objtool: Clobber user CFLAGS variable
If the build user has the CFLAGS variable set in their environment, objtool blindly appends to it, which can cause unexpected behavior.
Clobber CFLAGS to ensur
objtool: Clobber user CFLAGS variable
If the build user has the CFLAGS variable set in their environment, objtool blindly appends to it, which can cause unexpected behavior.
Clobber CFLAGS to ensure consistent objtool compilation behavior.
Reported-by: Valdis Kletnieks <valdis.kletnieks@vt.edu> Tested-by: Valdis Kletnieks <valdis.kletnieks@vt.edu> Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: https://lkml.kernel.org/r/83a276df209962e6058fcb6c615eef9d401c21bc.1567121311.git.jpoimboe@redhat.com Signed-off-by: Ingo Molnar <mingo@kernel.org>
show more ...
|
#
d046b725 |
| 29-Aug-2019 |
Josh Poimboeuf <jpoimboe@redhat.com> |
objtool: Move x86 insn decoder to a common location
The kernel tree has three identical copies of the x86 instruction decoder. Two of them are in the tools subdir.
The tools subdir is supposed to
objtool: Move x86 insn decoder to a common location
The kernel tree has three identical copies of the x86 instruction decoder. Two of them are in the tools subdir.
The tools subdir is supposed to be completely standalone and separate from the kernel. So having at least one copy of the kernel decoder in the tools subdir is unavoidable. However, we don't need *two* of them.
Move objtool's copy of the decoder to a shared location, so that perf will also be able to use it.
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com> Reviewed-by: Masami Hiramatsu <mhiramat@kernel.org> Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: Jiri Olsa <jolsa@redhat.com> Cc: x86@kernel.org Link: http://lore.kernel.org/lkml/55b486b88f6bcd0c9a2a04b34f964860c8390ca8.1567118001.git.jpoimboe@redhat.com Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
show more ...
|
Revision tags: v5.2.11, v5.2.10, v5.2.9, v5.2.8, v5.2.7, v5.2.6, v5.2.5, v5.2.4, v5.2.3, v5.2.2, v5.2.1, v5.2, v5.1.16, v5.1.15, v5.1.14, v5.1.13, v5.1.12, v5.1.11, v5.1.10, v5.1.9, v5.1.8, v5.1.7, v5.1.6, v5.1.5, v5.1.4 |
|
#
8ea58f1e |
| 16-May-2019 |
Nathan Chancellor <natechancellor@gmail.com> |
objtool: Allow AR to be overridden with HOSTAR
Currently, this Makefile hardcodes GNU ar, meaning that if it is not available, there is no way to supply a different one and the build will fail.
$
objtool: Allow AR to be overridden with HOSTAR
Currently, this Makefile hardcodes GNU ar, meaning that if it is not available, there is no way to supply a different one and the build will fail.
$ make AR=llvm-ar CC=clang LD=ld.lld HOSTAR=llvm-ar HOSTCC=clang \ HOSTLD=ld.lld HOSTLDFLAGS=-fuse-ld=lld defconfig modules_prepare ... AR /out/tools/objtool/libsubcmd.a /bin/sh: 1: ar: not found ...
Follow the logic of HOST{CC,LD} and allow the user to specify a different ar tool via HOSTAR (which is used elsewhere in other tools/ Makefiles).
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Reviewed-by: Mukesh Ojha <mojha@codeaurora.org> Cc: <stable@vger.kernel.org> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Link: http://lkml.kernel.org/r/80822a9353926c38fd7a152991c6292491a9d0e8.1558028966.git.jpoimboe@redhat.com Link: https://github.com/ClangBuiltLinux/linux/issues/481 Signed-off-by: Ingo Molnar <mingo@kernel.org>
show more ...
|
Revision tags: v5.1.3, v5.1.2, v5.1.1, v5.0.14, v5.1, v5.0.13, v5.0.12, v5.0.11, v5.0.10, v5.0.9, v5.0.8, v5.0.7, v5.0.6, v5.0.5 |
|
#
056d28d1 |
| 26-Mar-2019 |
Rolf Eike Beer <eb@emlix.com> |
objtool: Query pkg-config for libelf location
If it is not in the default location, compilation fails at several points.
Signed-off-by: Rolf Eike Beer <eb@emlix.com> Signed-off-by: Josh Poimboeuf <
objtool: Query pkg-config for libelf location
If it is not in the default location, compilation fails at several points.
Signed-off-by: Rolf Eike Beer <eb@emlix.com> Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com> Signed-off-by: Thomas Gleixner <tglx@linutronix.de> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/91a25e992566a7968fedc89ec80e7f4c83ad0548.1553622500.git.jpoimboe@redhat.com
show more ...
|
Revision tags: v5.0.4, v5.0.3, v4.19.29, v5.0.2, v4.19.28, v5.0.1, v4.19.27, v5.0, v4.19.26, v4.19.25, v4.19.24, v4.19.23, v4.19.22, v4.19.21, v4.19.20, v4.19.19, v4.19.18, v4.19.17, v4.19.16, v4.19.15, v4.19.14, v4.19.13, v4.19.12, v4.19.11, v4.19.10, v4.19.9, v4.19.8, v4.19.7, v4.19.6, v4.19.5, v4.19.4, v4.18.20, v4.19.3, v4.18.19, v4.19.2, v4.18.18, v4.18.17, v4.19.1, v4.19, v4.18.16, v4.18.15, v4.18.14, v4.18.13, v4.18.12, v4.18.11, v4.18.10, v4.18.9, v4.18.7, v4.18.6, v4.18.5, v4.17.18, v4.18.4, v4.18.3, v4.17.17, v4.18.2, v4.17.16, v4.17.15, v4.18.1, v4.18, v4.17.14, v4.17.13, v4.17.12, v4.17.11, v4.17.10, v4.17.9, v4.17.8, v4.17.7, v4.17.6 |
|
#
b90a3680 |
| 09-Jul-2018 |
Laura Abbott <labbott@redhat.com> |
kbuild: Rename HOSTLDFLAGS to KBUILD_HOSTLDFLAGS
In preparation for enabling command line LDFLAGS, re-name HOSTLDFLAGS to KBUILD_HOSTLDFLAGS as the internal use only flags. This should not have any
kbuild: Rename HOSTLDFLAGS to KBUILD_HOSTLDFLAGS
In preparation for enabling command line LDFLAGS, re-name HOSTLDFLAGS to KBUILD_HOSTLDFLAGS as the internal use only flags. This should not have any visible effects.
Signed-off-by: Laura Abbott <labbott@redhat.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
show more ...
|
#
96f14fe7 |
| 09-Jul-2018 |
Laura Abbott <labbott@redhat.com> |
kbuild: Rename HOSTCFLAGS to KBUILD_HOSTCFLAGS
In preparation for enabling command line CFLAGS, re-name HOSTCFLAGS to KBUILD_HOSTCFLAGS as the internal use only flags. This should not have any visib
kbuild: Rename HOSTCFLAGS to KBUILD_HOSTCFLAGS
In preparation for enabling command line CFLAGS, re-name HOSTCFLAGS to KBUILD_HOSTCFLAGS as the internal use only flags. This should not have any visible effects.
Signed-off-by: Laura Abbott <labbott@redhat.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
show more ...
|