Since commit bcf637f5 ("kbuild: parse C= and M= before changing the
working directory"), external module builds invoked by DKMS fail because
M= option is not parsed.

I wanted to add 'unset sub_make_done' in install.sh but similar scripts,
arch/*/boot/install.sh, are duplicated, so I set sub_make_done empty in
the top Makefile.

Fixes: bcf637f5 ("kbuild: parse C= and M= before changing the working directory")
Reported-by: NJohn S Gruber <johnsgruber@gmail.com>
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
Tested-by: NJohn S Gruber <johnsgruber@gmail.com>

When building ARCH=riscv allmodconfig with llvm-objcopy, the objcopy
version warning from this script appears:

WARNING: could not find objcopy version or version is less than 2.17.
        Local function references are disabled.

The check_objcopy() function in scripts/recordmcount.pl is set up to
parse GNU objcopy's version string, not llvm-objcopy's, which triggers
the warning.

Commit 799c4341 ("kbuild: thin archives make default for all archs")
made binutils 2.20 mandatory and commit ba64beb1 ("kbuild: check the
minimum assembler version in Kconfig") enforces this at configuration
time so just remove check_objcopy() and $can_use_local instead, assuming
--globalize-symbol is always available.

llvm-objcopy has supported --globalize-symbol since LLVM 7.0.0 in 2018
and the minimum version for building the kernel with LLVM is 10.0.1 so
there is no issue introduced:

Link: https://github.com/llvm/llvm-project/commit/ee5be798dae30d5f9414b01f76ff807edbc881aa
Link: https://lkml.kernel.org/r/20210802210307.3202472-1-nathan@kernel.orgReviewed-by: NNick Desaulniers <ndesaulniers@google.com>
Signed-off-by: NNathan Chancellor <nathan@kernel.org>
Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>

When a new CONFIG option is available, Kbuild shows a prompt to get
the user input.

  $ make
  [ snip ]
  Core Scheduling for SMT (SCHED_CORE) [N/y/?] (NEW)

This is the only interactive place in the build process.

Commit 174a1dcc ("kbuild: sink stdout from cmd for silent build")
suppressed Kconfig prompts as well because syncconfig is invoked by
the 'cmd' macro. You cannot notice the fact that Kconfig is waiting
for the user input.

Use 'kecho' to show the equivalent short log without suppressing stdout
from sub-make.

Fixes: 174a1dcc ("kbuild: sink stdout from cmd for silent build")
Reported-by: NTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
Tested-by: NTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>

This reverts commit b7eb335e.

It turns out that the problem with the clang -Wimplicit-fallthrough
warning is not about the kernel source code, but about clang itself, and
that the warning is unusable until clang fixes its broken ways.

In particular, when you enable this warning for clang, you not only get
warnings about implicit fallthroughs.  You also get this:

   warning: fallthrough annotation in unreachable code [-Wimplicit-fallthrough]

which is completely broken becasue it

 (a) doesn't even tell you where the problem is (seriously: no line
     numbers, no filename, no nothing).

 (b) is fundamentally broken anyway, because there are perfectly valid
     reasons to have a fallthrough statement even if it turns out that
     it can perhaps not be reached.

In the kernel, an example of that second case is code in the scheduler:

                switch (state) {
                case cpuset:
                        if (IS_ENABLED(CONFIG_CPUSETS)) {
                                cpuset_cpus_allowed_fallback(p);
                                state = possible;
                                break;
                        }
                        fallthrough;
                case possible:

where if CONFIG_CPUSETS is enabled you actually never hit the
fallthrough case at all.  But that in no way makes the fallthrough
wrong.

So the warning is completely broken, and enabling it for clang is a very
bad idea.

In the meantime, we can keep the gcc option enabled, and make the gcc
build use

    -Wimplicit-fallthrough=5

which means that we will at least continue to require a proper
fallthrough statement, and that gcc won't silently accept the magic
comment versions. Because gcc does this all correctly, and while the odd
"=5" part is kind of obscure, it's documented in [1]:

  "-Wimplicit-fallthrough=5 doesn’t recognize any comments as
   fallthrough comments, only attributes disable the warning"

so if clang ever fixes its bad behavior we can try enabling it there again.

Link: https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html [1]
Cc: Kees Cook <keescook@chromium.org>
Cc: Gustavo A. R. Silva <gustavoars@kernel.org>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>

With the recent fixes for fallthrough warnings, it is now possible to
enable -Wimplicit-fallthrough for Clang.

It's important to mention that since we have adopted the use of the
pseudo-keyword macro fallthrough; we also want to avoid having more
/* fall through */ comments being introduced. Notice that contrary
to GCC, Clang doesn't recognize any comments as implicit fall-through
markings when the -Wimplicit-fallthrough option is enabled. So, in
order to avoid having more comments being introduced, we have to use
the option -Wimplicit-fallthrough=5 for GCC, which similar to Clang,
will cause a warning in case a code comment is intended to be used
as a fall-through marking.
Co-developed-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NGustavo A. R. Silva <gustavoars@kernel.org>

M= (or KBUILD_EXTMOD) generally expects a directory path without any
trailing slashes, like M=a/b/c.

If you add a trailing slash, like M=a/b/c/, you will get ugly build
logs (two slashes in a series), but it still works fine as long as it
is consistent between 'make modules' and 'make modules_install'.

The following commands correctly build and install the modules.

  $ make M=a/b/c/ modules
  $ sudo make M=a/b/c/ modules_install

Since commit ccae4cfa ("kbuild: refactor scripts/Makefile.modinst"),
a problem happens if you add a trailing slash only for modules_install.

  $ make M=a/b/c modules
  $ sudo make M=a/b/c/ modules_install

No module is installed in this case, Johannes Berg reported. [1]

Trim any trailing slashes from $(KBUILD_EXTMOD).

I used the 'dirname' command to remove all the trailing slashes in
case someone adds more slashes like M=a/b/c/////. The Make's built-in
function, $(dir ...) cannot take care of such a case.

[1]: https://lore.kernel.org/lkml/10cc8522b27a051e6a9c3e158a4c4b6414fd04a0.camel@sipsolutions.net/

Fixes: ccae4cfa ("kbuild: refactor scripts/Makefile.modinst")
Reported-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>

Since LLVM commit fc018eb, the '-warn-stack-size' flag has been dropped
[1], leading to the following error message when building with Clang-13
and LLD-13:

    ld.lld: error: -plugin-opt=-: ld.lld: Unknown command line argument
    '-warn-stack-size=2048'.  Try: 'ld.lld --help'
    ld.lld: Did you mean '--asan-stack=2048'?

In the same way as with commit 2398ce80 ("x86, lto: Pass
-stack-alignment only on LLD < 13.0.0") , make '-warn-stack-size'
conditional on LLD < 13.0.0.

[1] https://reviews.llvm.org/D103928

Fixes: 24845dcb ("Makefile: LTO: have linker check -Wframe-larger-than")
Cc: stable@vger.kernel.org
Link: https://github.com/ClangBuiltLinux/linux/issues/1377Signed-off-by: NTor Vic <torvic9@mailbox.org>
Reviewed-by: NNathan Chancellor <nathan@kernel.org>
Reviewed-by: NNick Desaulniers <ndesaulniers@google.com>
Signed-off-by: NKees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/7631bab7-a8ab-f884-ab54-f4198976125c@mailbox.org

GDB produces the following warning when debugging kernels built with
CONFIG_RELR:

BFD: /android0/linux-next/vmlinux: unknown type [0x13] section `.relr.dyn'

when loading a kernel built with CONFIG_RELR into GDB. It can also
prevent debugging symbols using such relocations.

Peter sugguests:
  [That flag] means that lld will use dynamic tags and section type
  numbers in the OS-specific range rather than the generic range. The
  kernel itself doesn't care about these numbers; it determines the
  location of the RELR section using symbols defined by a linker script.

Link: https://github.com/ClangBuiltLinux/linux/issues/1057Suggested-by: NPeter Collingbourne <pcc@google.com>
Reviewed-by: NNathan Chancellor <nathan@kernel.org>
Signed-off-by: NNick Desaulniers <ndesaulniers@google.com>
Link: https://lore.kernel.org/r/20210522012626.2811297-1-ndesaulniers@google.comSigned-off-by: NWill Deacon <will@kernel.org>

scripts/mkmakefile is simple enough to be merged in the Makefile.

Use $(call cmd,...) to show the log instead of doing it in the
shell script.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>

arch/$(SRCARCH)/Kbuild is useful for Makefile cleanups because you can
use the obj-y syntax.

Add an empty file if it is missing in arch/$(SRCARCH)/.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>

-Wframe-larger-than= requires stack frame information, which the
frontend cannot provide. This diagnostic is emitted late during
compilation once stack frame size is available.

When building with LTO, the frontend simply lowers C to LLVM IR and does
not have stack frame information, so it cannot emit this diagnostic.
When the linker drives LTO, it restarts optimizations and lowers LLVM IR
to object code. At that point, it has stack frame information but
doesn't know to check for a specific max stack frame size.

I consider this a bug in LLVM that we need to fix. There are some
details we're working out related to LTO such as which value to use when
there are multiple different values specified per TU, or how to
propagate these to compiler synthesized routines properly, if at all.

Until it's fixed, ensure we don't miss these. At that point we can wrap
this in a compiler version guard or revert this based on the minimum
support version of Clang.

The error message is not generated during link:
  LTO     vmlinux.o
ld.lld: warning: stack size limit exceeded (8224) in foobarbaz

Cc: Sami Tolvanen <samitolvanen@google.com>
Reported-by: Candle Sun <candlesea@gmail.com>
Suggested-by: NFangrui Song <maskray@google.com>
Signed-off-by: NNick Desaulniers <ndesaulniers@google.com>
Signed-off-by: NKees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20210312010942.1546679-1-ndesaulniers@google.com

I do not see a good reason why only the libelf development package must
be so carefully checked.

Kbuild generally does not check host tools or libraries.

For example, x86_64 defconfig fails to build with no libssl development
package installed.

scripts/extract-cert.c:21:10: fatal error: openssl/bio.h: No such file or directory
   21 | #include <openssl/bio.h>
      |          ^~~~~~~~~~~~~~~

To solve the build error, you need to install libssl-dev or openssl-devel
package, depending on your distribution.

'apt-file search', 'dnf provides', etc. is your frined to find a proper
package to install.

This commit removes all the libelf checks from the top Makefile.

If libelf is missing, objtool will fail to build in a similar pattern:

.../linux/tools/objtool/include/objtool/elf.h:10:10: fatal error: gelf.h: No such file or directory
   10 | #include <gelf.h>

You need to install libelf-dev, libelf-devel, or elfutils-libelf-devel
to proceed.

Another remarkable change is, CONFIG_STACK_VALIDATION (without
CONFIG_UNWINDER_ORC) previously continued to build with a warning,
but now it will treat missing libelf as an error.

This is just a one-time installation, so it should not hurt to break
a build and make a user install the package.

BTW, the traditional way to handle such checks is autotool, but according
to [1], I do not expect the kernel build would have similar scripting
like './configure' does.

[1]: https://lore.kernel.org/lkml/CA+55aFzr2HTZVOuzpHYDwmtRJLsVzE-yqg2DHpHi_9ePsYp5ug@mail.gmail.com/Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
Acked-by: NAndrii Nakryiko <andrii@kernel.org>

The tools/ directory only exists in the kernel source tree, not in
external modules.

Do not expose the meaningless targets to external modules.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>

Commit 09c60546 ("./Makefile: add debug option to enable
function aligned on 32 bytes") was introduced to help debugging
strange kernel performance changes caused by code alignment
change.

Recently we found 2 similar cases [1][2] caused by code-alignment
changes, which can only be identified by forcing 64 bytes aligned
for all functions.

Originally, 32 bytes was used mainly for not wasting too much
text space, but this option is only for debug anyway where text
space is not a big concern. So extend the alignment to 64 bytes
to cover more similar cases.

[1].https://lore.kernel.org/lkml/20210427090013.GG32408@xsang-OptiPlex-9020/
[2].https://lore.kernel.org/lkml/20210420030837.GB31773@xsang-OptiPlex-9020/Signed-off-by: NFeng Tang <feng.tang@intel.com>
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>

The supported targets for external modules are listed in the help target
a few lines below. Let's not have duplicated information in two places.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>

'make tags' and friends create tag files in the top directory, but
people may manually create tag files in sub-directories.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>

This reverts the old commit [1], which seems questionable to me.

It claimed 'make distclean' could not remove editor backup files,
but I believe KBUILD_OUTPUT or O= was set.

When O= is given, Kbuild should always work against $(objtree).
If O= is not given, $(objtree) and $(srctree) are the same, therefore
$(srctree) is cleaned up.

[1]: https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/commit/?id=dd47df980c02eb33833b2690b033c34fba2fa80dSigned-off-by: NMasahiro Yamada <masahiroy@kernel.org>

Commit 37744fee ("sh: remove sh5 support") removed the SUPERH64
support entirely.

Remove the left-over code from the top Makefile.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
Acked-by: NArnd Bergmann <arnd@arndb.de>

Currently, -Wunused-but-set-variable is only supported by GCC so it is
disabled unconditionally in a GCC only block (it is enabled with W=1).
clang currently has its implementation for this warning in review so
preemptively move this statement out of the GCC only block and wrap it
with cc-disable-warning so that both compilers function the same.

Cc: stable@vger.kernel.org
Link: https://reviews.llvm.org/D100581Signed-off-by: NNathan Chancellor <nathan@kernel.org>
Reviewed-by: NNick Desaulniers <ndesaulniers@google.com>
Tested-by: NNick Desaulniers <ndesaulniers@google.com>
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>

We maintain .gitignore and Makefiles so build artifacts are properly
ignored by Git, and cleaned up by 'make clean'. However, the code is
always changing; generated files are often moved to another directory,
or removed when they become unnecessary. Such garbage files tend to be
left over in the source tree because people usually git-pull without
cleaning the tree.

This is not only the noise for 'git status', but also a build issue
in some cases.

One solution is to remove a stale file like commit 223c24a7 ("kbuild:
Automatically remove stale <linux/version.h> file") did. Such workaround
should be removed after a while, but we forget about that if we scatter
the workaround code in random places.

So, this commit adds a new script to collect cleanings of stale files.

As a start point, move the code in arch/arm/boot/compressed/Makefile
into this script.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>

Normally, invocations of $(HOSTCC) include $(KBUILD_HOSTLDFLAGS), which
in turn includes $(HOSTLDFLAGS), which allows users to pass in their own
flags when linking. However, the 'has_libelf' test does not, meaning
that if a user requests a specific linker via HOSTLDFLAGS=-fuse-ld=...,
it is not respected and the build might error.

For example, if a user building with clang wants to use all of the LLVM
tools without any GNU tools, they might remove all of the GNU tools from
their system or PATH then build with

$ make HOSTLDFLAGS=-fuse-ld=lld LLVM=1 LLVM_IAS=1

which says use all of the LLVM tools, the integrated assembler, and
ld.lld for linking host executables. Without this change, the build will
error because $(HOSTCC) uses its default linker, rather than the one
requested via -fuse-ld=..., which is GNU ld in clang's case in a default
configuration.

error: Cannot generate ORC metadata for CONFIG_UNWINDER_ORC=y, please
install libelf-dev, libelf-devel or elfutils-libelf-devel
make[1]: *** [Makefile:1260: prepare-objtool] Error 1

Add $(KBUILD_HOSTLDFLAGS) to the 'has_libelf' test so that the linker
choice is respected.

Link: https://github.com/ClangBuiltLinux/linux/issues/479Signed-off-by: NNathan Chancellor <nathan@kernel.org>
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>

scripts/Makefile.modsign is a subset of scripts/Makefile.modinst,
and duplicates the code. Let's merge them.

By the way, you do not need to run 'make modules_sign' explicitly
because modules are signed as a part of 'make modules_install' when
CONFIG_MODULE_SIG_ALL=y. If CONFIG_MODULE_SIG_ALL=n, mod_sign_cmd is
set to 'true', so 'make modules_sign' is not functional.

In my understanding, the reason of still keeping this is to handle
corner cases like commit 64178cb6 ("builddeb: fix stripped module
signatures if CONFIG_DEBUG_INFO and CONFIG_MODULE_SIG_ALL are set").
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>

Both mod_strip_cmd and mod_compress_cmd are only used in
scripts/Makefile.modinst, hence there is no good reason to define them
in the top Makefile. Move the relevant code to scripts/Makefile.modinst.

Also, show separate log messages for each of install, strip, sign, and
compress.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>