#
dc5723b0 |
| 11-Dec-2020 |
Sami Tolvanen <samitolvanen@google.com> |
kbuild: add support for Clang LTO
This change adds build system support for Clang's Link Time Optimization (LTO). With -flto, instead of ELF object files, Clang produces LLVM bitcode, which is compi
kbuild: add support for Clang LTO
This change adds build system support for Clang's Link Time Optimization (LTO). With -flto, instead of ELF object files, Clang produces LLVM bitcode, which is compiled into native code at link time, allowing the final binary to be optimized globally. For more details, see:
https://llvm.org/docs/LinkTimeOptimization.html
The Kconfig option CONFIG_LTO_CLANG is implemented as a choice, which defaults to LTO being disabled. To use LTO, the architecture must select ARCH_SUPPORTS_LTO_CLANG and support:
- compiling with Clang, - compiling all assembly code with Clang's integrated assembler, - and linking with LLD.
While using CONFIG_LTO_CLANG_FULL results in the best runtime performance, the compilation is not scalable in time or memory. CONFIG_LTO_CLANG_THIN enables ThinLTO, which allows parallel optimization and faster incremental builds. ThinLTO is used by default if the architecture also selects ARCH_SUPPORTS_LTO_CLANG_THIN:
https://clang.llvm.org/docs/ThinLTO.html
To enable LTO, LLVM tools must be used to handle bitcode files, by passing LLVM=1 and LLVM_IAS=1 options to make:
$ make LLVM=1 LLVM_IAS=1 defconfig $ scripts/config -e LTO_CLANG_THIN $ make LLVM=1 LLVM_IAS=1
To prepare for LTO support with other compilers, common parts are gated behind the CONFIG_LTO option, and LTO can be disabled for specific files by filtering out CC_FLAGS_LTO.
Signed-off-by: Sami Tolvanen <samitolvanen@google.com> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20201211184633.3213045-3-samitolvanen@google.com
show more ...
|
#
7c53f6b6 |
| 10-Jan-2021 |
Linus Torvalds <torvalds@linux-foundation.org> |
Linux 5.11-rc3
|
#
3b15cdc1 |
| 11-Dec-2020 |
Sami Tolvanen <samitolvanen@google.com> |
tracing: move function tracer options to Kconfig
Move function tracer options to Kconfig to make it easier to add new methods for generating __mcount_loc, and to make the options available also when
tracing: move function tracer options to Kconfig
Move function tracer options to Kconfig to make it easier to add new methods for generating __mcount_loc, and to make the options available also when building kernel modules.
Note that FTRACE_MCOUNT_USE_* options are updated on rebuild and therefore, work even if the .config was generated in a different environment.
Signed-off-by: Sami Tolvanen <samitolvanen@google.com> Acked-by: Steven Rostedt (VMware) <rostedt@goodmis.org> Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20201211184633.3213045-2-samitolvanen@google.com
show more ...
|
#
e71ba945 |
| 03-Jan-2021 |
Linus Torvalds <torvalds@linux-foundation.org> |
Linux 5.11-rc2
|
#
5c8fe583 |
| 27-Dec-2020 |
Linus Torvalds <torvalds@linux-foundation.org> |
Linux 5.11-rc1
|
#
436e980e |
| 01-Dec-2020 |
Dominique Martinet <asmadeus@codewreck.org> |
kbuild: don't hardcode depmod path
depmod is not guaranteed to be in /sbin, just let make look for it in the path like all the other invoked programs
Signed-off-by: Dominique Martinet <asmadeus@cod
kbuild: don't hardcode depmod path
depmod is not guaranteed to be in /sbin, just let make look for it in the path like all the other invoked programs
Signed-off-by: Dominique Martinet <asmadeus@codewreck.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
show more ...
|
#
2c85ebc5 |
| 13-Dec-2020 |
Linus Torvalds <torvalds@linux-foundation.org> |
Linux 5.10
|
#
0477e928 |
| 06-Dec-2020 |
Linus Torvalds <torvalds@linux-foundation.org> |
Linux 5.10-rc7
|
#
59612b24 |
| 19-Nov-2020 |
Nathan Chancellor <natechancellor@gmail.com> |
kbuild: Hoist '--orphan-handling' into Kconfig
Currently, '--orphan-handling=warn' is spread out across four different architectures in their respective Makefiles, which makes it a little unruly to
kbuild: Hoist '--orphan-handling' into Kconfig
Currently, '--orphan-handling=warn' is spread out across four different architectures in their respective Makefiles, which makes it a little unruly to deal with in case it needs to be disabled for a specific linker version (in this case, ld.lld 10.0.1).
To make it easier to control this, hoist this warning into Kconfig and the main Makefile so that disabling it is simpler, as the warning will only be enabled in a couple places (main Makefile and a couple of compressed boot folders that blow away LDFLAGS_vmlinx) and making it conditional is easier due to Kconfig syntax. One small additional benefit of this is saving a call to ld-option on incremental builds because we will have already evaluated it for CONFIG_LD_ORPHAN_WARN.
To keep the list of supported architectures the same, introduce CONFIG_ARCH_WANT_LD_ORPHAN_WARN, which an architecture can select to gain this automatically after all of the sections are specified and size asserted. A special thanks to Kees Cook for the help text on this config.
Link: https://github.com/ClangBuiltLinux/linux/issues/1187 Acked-by: Kees Cook <keescook@chromium.org> Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc) Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Tested-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
show more ...
|
#
b6505459 |
| 29-Nov-2020 |
Linus Torvalds <torvalds@linux-foundation.org> |
Linux 5.10-rc6
|
#
b8a90923 |
| 09-Nov-2020 |
Nick Desaulniers <ndesaulniers@google.com> |
Kbuild: do not emit debug info for assembly with LLVM_IAS=1
Clang's integrated assembler produces the warning for assembly files:
warning: DWARF2 only supports one section per compilation unit
If
Kbuild: do not emit debug info for assembly with LLVM_IAS=1
Clang's integrated assembler produces the warning for assembly files:
warning: DWARF2 only supports one section per compilation unit
If -Wa,-gdwarf-* is unspecified, then debug info is not emitted for assembly sources (it is still emitted for C sources). This will be re-enabled for newer DWARF versions in a follow up patch.
Enables defconfig+CONFIG_DEBUG_INFO to build cleanly with LLVM=1 LLVM_IAS=1 for x86_64 and arm64.
Cc: <stable@vger.kernel.org> Link: https://github.com/ClangBuiltLinux/linux/issues/716 Reported-by: Dmitry Golovin <dima@golovin.in> Reported-by: Nathan Chancellor <natechancellor@gmail.com> Suggested-by: Dmitry Golovin <dima@golovin.in> Suggested-by: Nathan Chancellor <natechancellor@gmail.com> Suggested-by: Sedat Dilek <sedat.dilek@gmail.com> Reviewed-by: Fangrui Song <maskray@google.com> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
show more ...
|
#
a716bd74 |
| 02-Nov-2020 |
Denys Zagorui <dzagorui@cisco.com> |
kbuild: use -fmacro-prefix-map for .S sources
Follow-up to commit a73619a845d5 ("kbuild: use -fmacro-prefix-map to make __FILE__ a relative path"). Assembler sources also use __FILE__ macro so this
kbuild: use -fmacro-prefix-map for .S sources
Follow-up to commit a73619a845d5 ("kbuild: use -fmacro-prefix-map to make __FILE__ a relative path"). Assembler sources also use __FILE__ macro so this flag should be also applied to those sources.
Signed-off-by: Denys Zagorui <dzagorui@cisco.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
show more ...
|
#
418baf2c |
| 22-Nov-2020 |
Linus Torvalds <torvalds@linux-foundation.org> |
Linux 5.10-rc5
|
#
09162bc3 |
| 16-Nov-2020 |
Linus Torvalds <torvalds@linux-foundation.org> |
Linux 5.10-rc4
|
#
f8394f23 |
| 09-Nov-2020 |
Linus Torvalds <torvalds@linux-foundation.org> |
Linux 5.10-rc3
|
#
d9b5665f |
| 23-Oct-2020 |
Vasily Gorbik <gor@linux.ibm.com> |
kbuild: remove unused OBJSIZE
The "size" tool has been solely used by s390 to enforce .bss section usage restrictions in early startup code. Since commit 980d5f9ab36b ("s390/boot: enable .bss sectio
kbuild: remove unused OBJSIZE
The "size" tool has been solely used by s390 to enforce .bss section usage restrictions in early startup code. Since commit 980d5f9ab36b ("s390/boot: enable .bss section for compressed kernel") and commit 2e83e0eb85ca ("s390: clean .bss before running uncompressed kernel") these restrictions have been lifted for the decompressor and uncompressed kernel and the size tool is now unused.
Signed-off-by: Vasily Gorbik <gor@linux.ibm.com> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
show more ...
|
#
3cea11cd |
| 01-Nov-2020 |
Linus Torvalds <torvalds@linux-foundation.org> |
Linux 5.10-rc2
|
#
3650b228 |
| 25-Oct-2020 |
Linus Torvalds <torvalds@linux-foundation.org> |
Linux 5.10-rc1
|
#
121c5d08 |
| 17-Oct-2020 |
Mark Wielaard <mark@klomp.org> |
kbuild: Only add -fno-var-tracking-assignments for old GCC versions
Some old GCC versions between 4.5.0 and 4.9.1 might miscompile code with -fvar-tracking-assingments (which is enabled by default w
kbuild: Only add -fno-var-tracking-assignments for old GCC versions
Some old GCC versions between 4.5.0 and 4.9.1 might miscompile code with -fvar-tracking-assingments (which is enabled by default with -g -O2). Commit 2062afb4f804 ("Fix gcc-4.9.0 miscompilation of load_balance() in scheduler") added -fno-var-tracking-assignments unconditionally to work around this. But newer versions of GCC no longer have this bug, so only add it for versions of GCC before 5.0. This allows various tools such as a perf probe or gdb debuggers or systemtap to resolve variable locations using dwarf locations in more code.
Signed-off-by: Mark Wielaard <mark@klomp.org> Acked-by: Ian Rogers <irogers@google.com> Reviewed-by: Andi Kleen <andi@firstfloor.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
show more ...
|
#
4c207c50 |
| 13-Oct-2020 |
Nick Desaulniers <ndesaulniers@google.com> |
Revert "kbuild: disable clang's default use of -fmerge-all-constants"
This reverts commit 87e0d4f0f37fb0c8c4aeeac46fff5e957738df79.
-fno-merge-all-constants has been the default since clang-6; the
Revert "kbuild: disable clang's default use of -fmerge-all-constants"
This reverts commit 87e0d4f0f37fb0c8c4aeeac46fff5e957738df79.
-fno-merge-all-constants has been the default since clang-6; the minimum supported version of clang in the kernel is clang-10 (10.0.1).
Suggested-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Tested-by: Sedat Dilek <sedat.dilek@gmail.com> Reviewed-by: Fangrui Song <maskray@google.com> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Reviewed-by: Sedat Dilek <sedat.dilek@gmail.com> Reviewed-by: Kees Cook <keescook@chromium.org> Cc: Andrey Konovalov <andreyknvl@google.com> Cc: Marco Elver <elver@google.com> Cc: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com> Cc: Alexei Starovoitov <ast@kernel.org> Cc: Daniel Borkmann <daniel@iogearbox.net> Cc: Masahiro Yamada <masahiroy@kernel.org> Cc: Vincenzo Frascino <vincenzo.frascino@arm.com> Cc: Will Deacon <will@kernel.org> Link: https://lkml.kernel.org/r/20200902225911.209899-3-ndesaulniers@google.com Link: https://reviews.llvm.org/rL329300. Link: https://github.com/ClangBuiltLinux/linux/issues/9 Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
show more ...
|
#
172aad81 |
| 11-Oct-2020 |
Olaf Hering <olaf@aepfle.de> |
kbuild: enforce -Werror=return-type
Catch errors which at least gcc tolerates by default: warning: 'return' with no value, in function returning non-void [-Wreturn-type]
Signed-off-by: Olaf Hering
kbuild: enforce -Werror=return-type
Catch errors which at least gcc tolerates by default: warning: 'return' with no value, in function returning non-void [-Wreturn-type]
Signed-off-by: Olaf Hering <olaf@aepfle.de> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
show more ...
|
#
bbf5c979 |
| 11-Oct-2020 |
Linus Torvalds <torvalds@linux-foundation.org> |
Linux 5.9
|
#
7dfbea4c |
| 10-Oct-2020 |
Jacob Keller <jacob.e.keller@intel.com> |
scripts: remove namespace.pl
namespace.pl is intended to help locate symbols which are defined but are not used externally. The goal is to avoid bloat of the namespace in the resulting kernel image.
scripts: remove namespace.pl
namespace.pl is intended to help locate symbols which are defined but are not used externally. The goal is to avoid bloat of the namespace in the resulting kernel image.
The script relies on object data, and only finds unused symbols for the configuration used to generate that object data. This results in a lot of false positive warnings such as symbols only used by a single architecture, or symbols which are used externally only under certain configurations.
Running namespace.pl using allyesconfig, allmodconfig, and x86_64_defconfig yields the following results:
* allmodconfig * 11122 unique symbol names with no external reference * 1194 symbols listed as multiply defined * 214 symbols it can't resolve * allyesconfig * 10997 unique symbol names with no external reference * 1194 symbols listed as multiply defined * 214 symbols it can't resolve * x86_64_defconfig * 5757 unique symbol names with no external reference * 528 symbols listed as multiply defined * 154 symbols it can't resolve
The script also has no way to easily limit the scope of the checks to a given subset of the kernel, such as only checking for symbols defined within a module or subsystem.
Discussion on public mailing lists seems to indicate that many view the tool output as suspect or not very useful (see discussions at [1] and [2] for further context).
As described by Masahiro Yamada at [2], namespace.pl provides 3 types of checks: listing multiply defined symbols, resolving external symbols, and warnings about symbols with no reference.
The first category of issues is easily caught by the linker as any set of multiply defined symbols should fail to link. The second category of issues is also caught by linking, as undefined symbols would cause issues. Even with modules, these types of issues where a module relies on an external symbol are caught by modpost.
The remaining category of issues reported is the list of symbols with no external reference, and is the primary motivation of this script. However, it ought to be clear from the above examples that the output is difficult to sort through. Even allyesconfig has ~10000 entries.
The current submit-checklist indicates that patches ought to go through namespacecheck and fix any new issues arising. But that itself presents problems. As described at [1], many cases of reports are due to configuration where a function is used externally by some configuration settings. Prominent maintainers appear to dislike changes modify code such that symbols become static based on CONFIG_* flags ([3], and [4])
One possible solution is to adjust the advice and indicate that we only care about the output of namespacecheck on allyesconfig or allmodconfig builds...
However, given the discussion at [2], I suspect that few people are actively using this tool. It doesn't have a maintainer in the MAINTAINERS flie, and it produces so many warnings for unused symbols that it is difficult to use effectively. Thus, I propose we simply remove it.
[1] https://lore.kernel.org/netdev/20200708164812.384ae8ea@kicinski-fedora-pc1c0hjn.dhcp.thefacebook.com/ [2] https://lore.kernel.org/lkml/20190129204319.15238-1-jacob.e.keller@intel.com/ [3] https://lore.kernel.org/netdev/20190828.154744.2058157956381129672.davem@davemloft.net/ [4] https://lore.kernel.org/netdev/20190827210928.576c5fef@cakuba.netronome.com/
Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Acked-by: Randy Dunlap <rdunlap@infradead.org> Acked-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
show more ...
|
#
a9684337 |
| 22-Sep-2020 |
Bill Wendling <morbo@google.com> |
kbuild: explicitly specify the build id style
ld's --build-id defaults to "sha1" style, while lld defaults to "fast". The build IDs are very different between the two, which may confuse programs tha
kbuild: explicitly specify the build id style
ld's --build-id defaults to "sha1" style, while lld defaults to "fast". The build IDs are very different between the two, which may confuse programs that reference them.
Signed-off-by: Bill Wendling <morbo@google.com> Acked-by: David S. Miller <davem@davemloft.net> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
show more ...
|
#
549738f1 |
| 04-Oct-2020 |
Linus Torvalds <torvalds@linux-foundation.org> |
Linux 5.9-rc8
|