Since commit 7ecaf069 ("kbuild: move headers_check rule to
usr/include/Makefile"), 'make headers_check' is no-op.

This stub target is remaining here in case some scripts still invoke it.
In order to prompt people to remove stale code, show a noisy warning
message if used. The stub will be really removed after the Linux 5.15
release.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>

Since commit f2f02ebd ("kbuild: improve cc-option to clean up all
temporary files"), running 'make kernelversion' in a read-only source
tree emits a bunch of warnings:

  mkdir: cannot create directory '.tmp_12345': Permission denied

No-build targets such as kernelversion, clean, help, etc. do not
need to evaluate $(call cc-option,) or friends. Skip Makefile.compiler
so $(call cc-option,) becomes no-op.

This not only fixes the warnings, but also runs non-build targets much
faster.

Basically, all installation targets should also be non-build targets.
Unfortunately, vdso_install requires the compiler because it builds
vdso before installation. This is a problem that must be fixed by a
separate patch.
Reported-by: NIsrael Tsadok <itsadok@gmail.com>
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>

scripts/Kbuild.include is included everywhere, but macros such as
cc-option are needed by build targets only.

For example, when 'make clean' traverses the tree, it does not need
to evaluate $(call cc-option,).

Split cc-option, ld-option, etc. to scripts/Makefile.compiler, which
is only included from the top Makefile and scripts/Makefile.build.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>

VPATH is used in Kbuild to make pattern rules search for prerequisites
in both $(objtree) and $(srctree). Some of *.c, *.S files are not real
sources, but generated by tools such as flex, bison, perl.

In contrast, I doubt the benefit of --include-dir=$(abs_srctree) because
it is always clear which Makefiles are real sources, and which are not.

So, my hope is to add $(srctree)/ prefix to all check-in Makefiles,
then remove --include-dir=$(abs_srctree) flag in the future.

I am touching only some Kbuild core parts for now. Treewide fixes will
be needed to achieve this goal.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>

Linus reported a build error due to the GCC plugin incompatibility
when the compiler is upgraded. [1]

GCC plugins are tied to a particular GCC version. So, they must be
rebuilt when the compiler is upgraded.

This seems to be a long-standing flaw since the initial support of
GCC plugins.

Extend commit 8b59cd81 ("kbuild: ensure full rebuild when the
compiler is updated"), so that GCC plugins are covered by the
compiler upgrade detection.

[1]: https://lore.kernel.org/lkml/CAHk-=wieoN5ttOy7SnsGwZv+Fni3R6m-Ut=oxih6bbZ28G+4dw@mail.gmail.com/Reported-by: NLinus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
Reviewed-by: NKees Cook <keescook@chromium.org>

'make image_name' needs include/config/auto.conf to show the correct
output because KBUILD_IMAGE depends on CONFIG options, but should not
attempt to resync the configuration.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>

Commit 78d3bb44 ("kbuild: Fix <linux/version.h> for empty SUBLEVEL
or PATCHLEVEL") fixed the build error for empty SUBLEVEL or PATCHLEVEL
by prepending a zero.

Commit 9b82f13e ("kbuild: clamp SUBLEVEL to 255") re-introduced
this issue.

This time, we cannot take the same approach because we have C code:

  #define LINUX_VERSION_PATCHLEVEL $(PATCHLEVEL)
  #define LINUX_VERSION_SUBLEVEL $(SUBLEVEL)

Replace empty SUBLEVEL/PATCHLEVEL with a zero.

Fixes: 9b82f13e ("kbuild: clamp SUBLEVEL to 255")
Reported-by: NChristian Zigotzky <chzigotzky@xenosoft.de>
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
Reviewed-and-tested-by: NSasha Levin <sashal@kernel.org>

'make -s' should be really silent. However, 'make -s V=1' prints noisy
log messages from some shell scripts.

Of course, such a combination is odd, but the build system needs to do
the right thing even if a user gives strange input.

If -s is given, KBUILD_VERBOSE should be forced to 0.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>

Instead of 'make distclean', 'make clean' should remove build artifacts
unneeded by external module builds. Obviously, you do not need to keep
this directory.

Fixes: dc5723b0 ("kbuild: add support for Clang LTO")
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
Signed-off-by: NKees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20210225193912.3303604-1-masahiroy@kernel.org

If Kbuild recurses to the top Makefile (for example, 'make deb-pkg'),
C= and M= are parsed over again, needlessly.

Parse them before changing the working directory. After that,
sub_make_done is set to 1, so they are parsed just once.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>

Move this-makefile up, and reuse it to define abs_srctree.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>

When using AMD's Optimizing C/C++ Compiler (AOCC), the build fails due
to a # character in the version string, which is interpreted as a
comment:

$ make CC=clang defconfig init/main.o
include/config/auto.conf.cmd:1374: *** invalid syntax in conditional. Stop.

$ sed -n 1374p include/config/auto.conf.cmd
ifneq "$(CC_VERSION_TEXT)" "AMD clang version 11.0.0 (CLANG: AOCC_2.3.0-Build#85 2020_11_10) (based on LLVM Mirror.Version.11.0.0)"

Remove all # characters in the version string so that the build does not
fail unexpectedly.

Link: https://github.com/ClangBuiltLinux/linux/issues/1298Reported-by: NMichael Fuckner <michael@fuckner.net>
Signed-off-by: NNathan Chancellor <nathan@kernel.org>
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>

I noticed we're invoking $(CC) via $(shell) more than once to check the
version.  Let's reuse the first string captured in $CC_VERSION_TEXT.
Signed-off-by: NNick Desaulniers <ndesaulniers@google.com>
[masahiro.yamada:
CC_VERSION_TEXT is assigned by = instead of :=, so this $(shell ) is
evaluated multiple times anyway. The number of $(CC) invocations will
be still the same. Replacing 'grep' with the built-in $(findstring )
will give real performance benefit.]
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>

When doing non-clean builds and switching between CONFIG_LTO=n and
CONFIG_LTO=y, the build system (correctly) didn't notice that assembly
and LTO-excluded C object files were rewritten in place by objtool (to
add the .orc_unwind* sections), since their build command lines were the
same between CONFIG_LTO=y and CONFIG_LTO=n. The objtool step would fail:

vmlinux.o: warning: objtool: file already has .orc_unwind section, skipping
make: *** [Makefile:1194: vmlinux] Error 255

Avoid this by making sure the build will see a difference between an LTO
and non-LTO build (by including "-fno-lto" in KBUILD_*FLAGS). This will
get ignored when CC_FLAGS_LTO is present, and will not be included at
all when CONFIG_LTO=n.
Signed-off-by: NSami Tolvanen <samitolvanen@google.com>
Signed-off-by: NKees Cook <keescook@chromium.org>

This change adds build support for using objtool to generate
__mcount_loc sections.
Signed-off-by: NSami Tolvanen <samitolvanen@google.com>

CC_FLAGS_LTO gets initialized only via +=, never with := or =.
When building with CONFIG_TRIM_UNUSED_KSYMS, Kbuild may perform
several kernel rebuilds to satisfy symbol dependencies. In this
case, value of CC_FLAGS_LTO is concatenated each time, which
triggers a full rebuild.
Initialize it with := to fix this.

Fixes: dc5723b0 ("kbuild: add support for Clang LTO")
Signed-off-by: NAlexander Lobakin <alobakin@pm.me>
Signed-off-by: NKees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20210121184544.659998-1-alobakin@pm.me

Instead of storing the version in a single integer and having various
kernel (and userspace) code how it's constructed, export individual
(major, patchlevel, sublevel) components and simplify kernel code that
uses it.

This should also make it easier on userspace.
Signed-off-by: NSasha Levin <sashal@kernel.org>
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>

Right now if SUBLEVEL becomes larger than 255 it will overflow into the
territory of PATCHLEVEL, causing havoc in userspace that tests for
specific kernel version.

While userspace code tests for MAJOR and PATCHLEVEL, it doesn't test
SUBLEVEL at any point as ABI changes don't happen in the context of
stable tree.

Thus, to avoid overflows, simply clamp SUBLEVEL to it's maximum value in
the context of LINUX_VERSION_CODE. This does not affect "make
kernelversion" and such.
Signed-off-by: NSasha Levin <sashal@kernel.org>
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>

DWARF v5 is the latest standard of the DWARF debug info format. GCC 11
will change the implicit default DWARF version, if left unspecified, to
DWARF v5.

Allow users of Clang and older versions of GCC that have not changed the
implicit default DWARF version to DWARF v5 to opt in. This can help
testing consumers of DWARF debug info in preparation of v5 becoming more
widespread, as well as result in significant binary size savings of the
pre-stripped vmlinux image.

DWARF5 wins significantly in terms of size when mixed with compression
(CONFIG_DEBUG_INFO_COMPRESSED).

363M    vmlinux.clang12.dwarf5.compressed
434M    vmlinux.clang12.dwarf4.compressed
439M    vmlinux.clang12.dwarf2.compressed
457M    vmlinux.clang12.dwarf5
536M    vmlinux.clang12.dwarf4
548M    vmlinux.clang12.dwarf2

515M    vmlinux.gcc10.2.dwarf5.compressed
599M    vmlinux.gcc10.2.dwarf4.compressed
624M    vmlinux.gcc10.2.dwarf2.compressed
630M    vmlinux.gcc10.2.dwarf5
765M    vmlinux.gcc10.2.dwarf4
809M    vmlinux.gcc10.2.dwarf2

Though the quality of debug info is harder to quantify; size is not a
proxy for quality.

Jakub notes:
  One thing is GCC DWARF-5 support, that is whether the compiler will
  support -gdwarf-5 flag, and that support should be there from GCC 7
  onwards.

  All [GCC] 5.1 - 6.x did was start accepting -gdwarf-5 as experimental
  option that enabled some small DWARF subset (initially only a few
  DW_LANG_* codes newly added to DWARF5 drafts).  Only GCC 7 (released
  after DWARF 5 has been finalized) started emitting DWARF5 section
  headers and got most of the DWARF5 changes in...

  Another separate thing is whether the assembler does support
  the -gdwarf-5 option (i.e. if you can compile assembler files
  with -Wa,-gdwarf-5) ... That option is about whether the assembler
  will emit DWARF5 or DWARF2 .debug_line.  It is fine to compile C sources
  with -gdwarf-5 and use DWARF2 .debug_line for assembler files if as
  doesn't support it.

Version check GCC so that we don't need to worry about the difference in
command line args between GNU readelf and llvm-readelf/llvm-dwarfdump to
validate the DWARF Version in the assembler feature detection script.

Most issues with clang produced assembler were fixed in binutils 2.35.1,
but 2.35.2 fixed issues related to requiring the flag -Wa,-gdwarf-5
explicitly. The added shell script test checks for the latter, and is
only required when using clang without its integrated assembler, though
we use for clang regardless as we do not yet have a way to query the
assembler from Kconfig.

Disabled for now if CONFIG_DEBUG_INFO_BTF is set; pahole doesn't yet
recognize the new additions to the DWARF debug info.

This only modifies the DWARF version emitted by the compiler, not the
assembler.

The DWARF version of a binary can be validated with:
$ llvm-dwarfdump <object file> | head -n 4 | grep version
or
$ readelf --debug-dump=info <object file> 2>/dev/null | grep Version

Parts of the tree don't reuse DEBUG_CFLAGS as they should; such cleanup
is left as a follow up.

Link: http://www.dwarfstd.org/doc/DWARF5.pdf
Link: https://bugzilla.redhat.com/show_bug.cgi?id=1922707Reported-by: NSedat Dilek <sedat.dilek@gmail.com>
Suggested-by: NArvind Sankar <nivedita@alum.mit.edu>
Suggested-by: NCaroline Tice <cmtice@google.com>
Suggested-by: NFangrui Song <maskray@google.com>
Suggested-by: NJakub Jelinek <jakub@redhat.com>
Suggested-by: NMasahiro Yamada <masahiroy@kernel.org>
Suggested-by: NNathan Chancellor <natechancellor@gmail.com>
Signed-off-by: NNick Desaulniers <ndesaulniers@google.com>
Tested-by: Sedat Dilek <sedat.dilek@gmail.com> # LLVM/Clang v12.0.0-rc1 x86-64
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>

Adds a default CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT which allows
the implicit default version of DWARF emitted by the toolchain to
progress over time.

Modifies CONFIG_DEBUG_INFO_DWARF4 to be a member of a choice, making it
mutually exclusive with CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT. Users
may want to select this if they are using a newer toolchain, but have
consumers of the DWARF debug info that aren't yet ready for newer DWARF
versions' debug info.

Does so in a way that's forward compatible with existing
configs, and makes adding future versions more straightforward. This
patch does not change the current behavior or selection of DWARF
version for users upgrading to kernels with this patch.

GCC since ~4.8 has defaulted to DWARF v4 implicitly, and GCC 11 has
bumped this to v5.

Remove the Kconfig help text  about DWARF v4 being larger.  It's
empirically false for the latest toolchains for x86_64 defconfig, has no
point of reference (I suspect it was DWARF v2 but that's stil
empirically false), and debug info size is not a qualatative measure.
Suggested-by: NArvind Sankar <nivedita@alum.mit.edu>
Suggested-by: NFangrui Song <maskray@google.com>
Suggested-by: NJakub Jelinek <jakub@redhat.com>
Suggested-by: NMark Wielaard <mark@klomp.org>
Suggested-by: NMasahiro Yamada <masahiroy@kernel.org>
Suggested-by: NNathan Chancellor <nathan@kernel.org>
Tested-by: NSedat Dilek <sedat.dilek@gmail.com>
Signed-off-by: NNick Desaulniers <ndesaulniers@google.com>
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>

Revert commit 223c24a7 ("kbuild: Automatically remove stale
<linux/version.h> file").

It was more than 6 years ago. I do not expect anybody to start
git-bisect for such a big window.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>

By default, xz without parameters uses a dictionary size of 8 MB.
However, most modules are much smaller than that.
The xz manpage states that 'increasing dictionary size usually improves
compression ratio, but a dictionary bigger than the uncompressed file
is waste of memory'.
Use a dictionary size of 2 MB for module compression, resulting in
slightly higher compression speed while still maintaining a good
compression ratio.
Signed-off-by: NTor Vic <torvic9@mailbox.org>
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>

Nathan reported issue with cleaning empty build directory:

  $ make -s O=build distclean
  ../../scripts/Makefile.include:4: *** \
  O=/ho...build/tools/bpf/resolve_btfids does not exist.  Stop.

The problem that tools scripts require existing output
directory, otherwise it fails.

Adding check around the resolve_btfids clean target to
ensure the output directory is in place.
Signed-off-by: NJiri Olsa <jolsa@kernel.org>
Signed-off-by: NAndrii Nakryiko <andrii@kernel.org>
Tested-by: NNathan Chancellor <nathan@kernel.org>
Link: https://lore.kernel.org/bpf/20210211124004.1144344-1-jolsa@kernel.org

The resolve_btfids tool is used during the kernel build,
so we should clean it on kernel's make clean.

Invoking the the resolve_btfids clean as part of root
'make clean'.
Signed-off-by: NJiri Olsa <jolsa@kernel.org>
Signed-off-by: NAndrii Nakryiko <andrii@kernel.org>
Acked-by: NSong Liu <songliubraving@fb.com>
Link: https://lore.kernel.org/bpf/20210205124020.683286-5-jolsa@kernel.org

Sedat Dilek noticed duplicated flags in DEBUG_CFLAGS when building
deb-pkg with CONFIG_DEBUG_INFO. For example, 'make CC=clang bindeb-pkg'
reproduces the issue.

Kbuild recurses to the top Makefile for some targets such as package
builds.

With commit 121c5d08 ("kbuild: Only add -fno-var-tracking-assignments
for old GCC versions") applied, DEBUG_CFLAGS is now reset only when
CONFIG_CC_IS_GCC=y.

Fix it to reset DEBUG_CFLAGS all the time.

Fixes: 121c5d08 ("kbuild: Only add -fno-var-tracking-assignments for old GCC versions")
Reported-by: NSedat Dilek <sedat.dilek@gmail.com>
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
Tested-by: NSedat Dilek <sedat.dilek@gmail.com>
Reviewed-by: NMark Wielaard <mark@klomp.org>
Reviewed-by: NNathan Chancellor <nathan@kernel.org>

Add support for building DT overlays (%.dtbo). The overlay's source file
will have the usual extension, i.e. .dts, though the blob will have
.dtbo extension to distinguish it from normal blobs.
Acked-by: NMasahiro Yamada <masahiroy@kernel.org>
Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
Signed-off-by: NRob Herring <robh@kernel.org>
Link: https://lore.kernel.org/r/434ba2467dd0cd011565625aeb3450650afe0aae.1611904394.git.viresh.kumar@linaro.org

Python retired in 2020, and some distributions do not provide the
'python' command any more.

As in commit 51839e29 ("scripts: switch explicitly to Python 3"),
we need to use more specific 'python3' to invoke scripts even if they
are written in a way compatible with both Python 2 and 3.

This commit removes the variable 'PYTHON', and switches the existing
users to 'PYTHON3'.

BTW, PEP 394 (https://www.python.org/dev/peps/pep-0394/) is a helpful
material.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>

With retpolines disabled, some configurations of GCC, and specifically
the GCC versions 9 and 10 in Ubuntu will add Intel CET instrumentation
to the kernel by default. That breaks certain tracing scenarios by
adding a superfluous ENDBR64 instruction before the fentry call, for
functions which can be called indirectly.

CET instrumentation isn't currently necessary in the kernel, as CET is
only supported in user space. Disable it unconditionally and move it
into the x86's Makefile as CET/CFI... enablement should be a per-arch
decision anyway.

 [ bp: Massage and extend commit message. ]

Fixes: 29be86d7 ("kbuild: add -fcf-protection=none when using retpoline flags")
Reported-by: NNikolay Borisov <nborisov@suse.com>
Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: NBorislav Petkov <bp@suse.de>
Reviewed-by: NNikolay Borisov <nborisov@suse.com>
Tested-by: NNikolay Borisov <nborisov@suse.com>
Cc: <stable@vger.kernel.org>
Cc: Seth Forshee <seth.forshee@canonical.com>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Link: https://lkml.kernel.org/r/20210128215219.6kct3h2eiustncws@treble

When CONFIG_NET is disabled, nothing under the net/ directory is
compiled. Move the CONFIG_NET guard to the top Makefile so the net/
directory is entirely skipped.

When Kbuild visits net/Makefile, CONFIG_NET is obvioulsy 'y' because
CONFIG_NET is a bool option. Clean up net/Makefile.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
Link: https://lore.kernel.org/r/20210125231659.106201-1-masahiroy@kernel.orgSigned-off-by: NJakub Kicinski <kuba@kernel.org>

This change limits function inlining across translation unit boundaries
in order to reduce the binary size with LTO. The -import-instr-limit
flag defines a size limit, as the number of LLVM IR instructions, for
importing functions from other TUs, defaulting to 100.

Based on testing with arm64 defconfig, we found that a limit of 5 is a
reasonable compromise between performance and binary size, reducing the
size of a stripped vmlinux by 11%.
Suggested-by: NGeorge Burgess IV <gbiv@google.com>
Signed-off-by: NSami Tolvanen <samitolvanen@google.com>
Reviewed-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NKees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20201211184633.3213045-5-samitolvanen@google.com

With CONFIG_MODVERSIONS, version information is linked into each
compilation unit that exports symbols. With LTO, we cannot use this
method as all C code is compiled into LLVM bitcode instead. This
change collects symbol versions into .symversions files and merges
them in link-vmlinux.sh where they are all linked into vmlinux.o at
the same time.
Signed-off-by: NSami Tolvanen <samitolvanen@google.com>
Reviewed-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NKees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20201211184633.3213045-4-samitolvanen@google.com

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: NSami Tolvanen <samitolvanen@google.com>
Reviewed-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NKees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20201211184633.3213045-3-samitolvanen@google.com