License cleanup: add SPDX GPL-2.0 license identifier to files with no license
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.
By default all files without license information are under the default
license of the kernel, which is GPL version 2.
Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.
This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.
How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,
Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.
The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.
The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.
Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if <5
lines).
All documentation files were explicitly excluded.
The following heuristics were used to determine which SPDX license
identifiers to apply.
- when both scanners couldn't find any license traces, file was
considered to have no license information in it, and the top level
COPYING file license applied.
For non */uapi/* files that summary was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 11139
and resulted in the first patch in this series.
If that file was a */uapi/* path one, it was "GPL-2.0 WITH
Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 WITH Linux-syscall-note 930
and resulted in the second patch in this series.
- if a file had some form of licensing information in it, and was one
of the */uapi/* ones, it was denoted with the Linux-syscall-note if
any GPL family license was found in the file or had no licensing in
it (per prior point). Results summary:
SPDX license identifier # files
---------------------------------------------------|------
GPL-2.0 WITH Linux-syscall-note 270
GPL-2.0+ WITH Linux-syscall-note 169
((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21
((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17
LGPL-2.1+ WITH Linux-syscall-note 15
GPL-1.0+ WITH Linux-syscall-note 14
((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5
LGPL-2.0+ WITH Linux-syscall-note 4
LGPL-2.1 WITH Linux-syscall-note 3
((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3
((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1
and that resulted in the third patch in this series.
- when the two scanners agreed on the detected license(s), that became
the concluded license(s).
- when there was disagreement between the two scanners (one detected a
license but the other didn't, or they both detected different
licenses) a manual inspection of the file occurred.
- In most cases a manual inspection of the information in the file
resulted in a clear resolution of the license that should apply (and
which scanner probably needed to revisit its heuristics).
- When it was not immediately clear, the license identifier was
confirmed with lawyers working with the Linux Foundation.
- If there was any question as to the appropriate license identifier,
the file was flagged for further research and to be revisited later
in time.
In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases, confirmation
by lawyers working with the Linux Foundation.
Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights. The
Windriver scanner is based on an older version of FOSSology in part, so
they are related.
Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot checks
in about 15000 files.
In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect the
correct identifier.
Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial patch
version early this week with:
- a full scancode scan run, collecting the matched texts, detected
license ids and scores
- reviewing anything where there was a license detected (about 500+
files) to ensure that the applied SPDX license was correct
- reviewing anything where there was no detection but the patch license
was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
SPDX license was correct
This produced a worksheet with 20 files needing minor correction. This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.
These .csv files were then reviewed by Greg. Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected. This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.) Finally Greg ran the script using the .csv files to
generate the patches.
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-01 14:07:57 +00:00
|
|
|
# SPDX-License-Identifier: GPL-2.0
|
2022-08-14 22:50:18 +00:00
|
|
|
VERSION = 6
|
2024-12-01 22:28:56 +00:00
|
|
|
PATCHLEVEL = 13
|
2011-05-30 00:43:36 +00:00
|
|
|
SUBLEVEL = 0
|
2024-12-22 21:22:21 +00:00
|
|
|
EXTRAVERSION = -rc4
|
2024-05-26 22:20:12 +00:00
|
|
|
NAME = Baby Opossum Posse
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
|
# *DOCUMENTATION*
|
|
|
|
|
# To see a list of typical targets execute "make help"
|
|
|
|
|
# More info can be located in ./README
|
|
|
|
|
# Comments in this file are targeted only to the developer, do not
|
|
|
|
|
# expect to learn how to build the kernel reading this file.
|
|
|
|
|
|
2024-07-04 13:47:55 +00:00
|
|
|
ifeq ($(filter output-sync,$(.FEATURES)),)
|
|
|
|
|
$(error GNU Make >= 4.0 is required. Your Make version is $(MAKE_VERSION))
|
2022-12-13 11:24:20 +00:00
|
|
|
endif
|
|
|
|
|
|
2020-05-11 03:50:13 +00:00
|
|
|
$(if $(filter __%, $(MAKECMDGOALS)), \
|
|
|
|
|
$(error targets prefixed with '__' are only for internal use))
|
|
|
|
|
|
2017-10-04 03:56:05 +00:00
|
|
|
# That's our default target when none is given on the command line
|
2020-05-11 03:50:13 +00:00
|
|
|
PHONY := __all
|
|
|
|
|
__all:
|
2017-10-04 03:56:05 +00:00
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
# We are using a recursive build, so we need to do a little thinking
|
|
|
|
|
# to get the ordering right.
|
|
|
|
|
#
|
|
|
|
|
# Most importantly: sub-Makefiles should only ever modify files in
|
|
|
|
|
# their own directory. If in some directory we have a dependency on
|
|
|
|
|
# a file in another dir (which doesn't happen often, but it's often
|
2018-02-10 14:25:04 +00:00
|
|
|
# unavoidable when linking the built-in.a targets which finally
|
2005-04-16 22:20:36 +00:00
|
|
|
# turn into vmlinux), we will call a sub make in that other dir, and
|
|
|
|
|
# after that we are sure that everything which is in that other dir
|
|
|
|
|
# is now up to date.
|
|
|
|
|
#
|
|
|
|
|
# The only cases where we need to modify files which have global
|
|
|
|
|
# effects are thus separated out and done before the recursive
|
|
|
|
|
# descending is started. They are now explicitly listed as the
|
|
|
|
|
# prepare rule.
|
|
|
|
|
|
2023-06-26 23:30:12 +00:00
|
|
|
this-makefile := $(lastword $(MAKEFILE_LIST))
|
2024-03-06 10:42:22 +00:00
|
|
|
abs_srctree := $(realpath $(dir $(this-makefile)))
|
2024-11-10 01:34:31 +00:00
|
|
|
abs_output := $(CURDIR)
|
2023-06-26 23:30:12 +00:00
|
|
|
|
2019-03-26 04:02:19 +00:00
|
|
|
ifneq ($(sub_make_done),1)
|
2019-02-22 07:40:07 +00:00
|
|
|
|
|
|
|
|
# Do not use make's built-in rules and variables
|
|
|
|
|
# (this increases performance and avoids hard-to-debug behaviour)
|
|
|
|
|
MAKEFLAGS += -rR
|
|
|
|
|
|
|
|
|
|
# Avoid funny character set dependencies
|
|
|
|
|
unexport LC_ALL
|
|
|
|
|
LC_COLLATE=C
|
|
|
|
|
LC_NUMERIC=C
|
|
|
|
|
export LC_COLLATE LC_NUMERIC
|
|
|
|
|
|
|
|
|
|
# Avoid interference with shell env settings
|
|
|
|
|
unexport GREP_OPTIONS
|
|
|
|
|
|
2014-07-04 12:29:30 +00:00
|
|
|
# Beautify output
|
|
|
|
|
# ---------------------------------------------------------------------------
|
|
|
|
|
#
|
2022-12-22 16:25:32 +00:00
|
|
|
# Most of build commands in Kbuild start with "cmd_". You can optionally define
|
|
|
|
|
# "quiet_cmd_*". If defined, the short log is printed. Otherwise, no log from
|
|
|
|
|
# that command is printed by default.
|
2014-07-04 12:29:30 +00:00
|
|
|
#
|
2022-12-22 16:25:32 +00:00
|
|
|
# e.g.)
|
|
|
|
|
# quiet_cmd_depmod = DEPMOD $(MODLIB)
|
|
|
|
|
# cmd_depmod = $(srctree)/scripts/depmod.sh $(DEPMOD) $(KERNELRELEASE)
|
2014-07-04 12:29:30 +00:00
|
|
|
#
|
|
|
|
|
# A simple variant is to prefix commands with $(Q) - that's useful
|
|
|
|
|
# for commands that shall be hidden in non-verbose mode.
|
|
|
|
|
#
|
2022-12-22 16:25:32 +00:00
|
|
|
# $(Q)$(MAKE) $(build)=scripts/basic
|
2014-07-04 12:29:30 +00:00
|
|
|
#
|
2022-12-22 16:25:34 +00:00
|
|
|
# If KBUILD_VERBOSE contains 1, the whole command is echoed.
|
|
|
|
|
# If KBUILD_VERBOSE contains 2, the reason for rebuilding is printed.
|
2014-07-04 12:29:30 +00:00
|
|
|
#
|
2005-04-16 22:20:36 +00:00
|
|
|
# To put more focus on warnings, be less verbose as default
|
|
|
|
|
# Use 'make V=1' to see the full commands
|
|
|
|
|
|
2009-05-26 08:03:07 +00:00
|
|
|
ifeq ("$(origin V)", "command line")
|
|
|
|
|
KBUILD_VERBOSE = $(V)
|
2005-04-16 22:20:36 +00:00
|
|
|
endif
|
|
|
|
|
|
2022-12-22 16:25:34 +00:00
|
|
|
quiet = quiet_
|
|
|
|
|
Q = @
|
|
|
|
|
|
|
|
|
|
ifneq ($(findstring 1, $(KBUILD_VERBOSE)),)
|
2014-07-04 12:29:30 +00:00
|
|
|
quiet =
|
|
|
|
|
Q =
|
|
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
# If the user is running make -s (silent mode), suppress echoing of
|
|
|
|
|
# commands
|
2024-07-04 13:47:55 +00:00
|
|
|
ifneq ($(findstring s,$(firstword -$(MAKEFLAGS))),)
|
2022-12-05 21:48:19 +00:00
|
|
|
quiet=silent_
|
2022-12-22 16:25:35 +00:00
|
|
|
override KBUILD_VERBOSE :=
|
2014-07-04 12:29:30 +00:00
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
export quiet Q KBUILD_VERBOSE
|
|
|
|
|
|
2021-02-21 16:53:06 +00:00
|
|
|
# Call a source code checker (by default, "sparse") as part of the
|
|
|
|
|
# C compilation.
|
|
|
|
|
#
|
|
|
|
|
# Use 'make C=1' to enable checking of only re-compiled files.
|
|
|
|
|
# Use 'make C=2' to enable checking of *all* source files, regardless
|
|
|
|
|
# of whether they are re-compiled or not.
|
|
|
|
|
#
|
|
|
|
|
# See the file "Documentation/dev-tools/sparse.rst" for more details,
|
|
|
|
|
# including where to get the "sparse" utility.
|
|
|
|
|
|
|
|
|
|
ifeq ("$(origin C)", "command line")
|
|
|
|
|
KBUILD_CHECKSRC = $(C)
|
|
|
|
|
endif
|
|
|
|
|
ifndef KBUILD_CHECKSRC
|
|
|
|
|
KBUILD_CHECKSRC = 0
|
|
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
export KBUILD_CHECKSRC
|
|
|
|
|
|
2021-07-03 14:42:57 +00:00
|
|
|
# Enable "clippy" (a linter) as part of the Rust compilation.
|
|
|
|
|
#
|
|
|
|
|
# Use 'make CLIPPY=1' to enable it.
|
|
|
|
|
ifeq ("$(origin CLIPPY)", "command line")
|
|
|
|
|
KBUILD_CLIPPY := $(CLIPPY)
|
|
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
export KBUILD_CLIPPY
|
|
|
|
|
|
2021-02-21 16:53:06 +00:00
|
|
|
# Use make M=dir or set the environment variable KBUILD_EXTMOD to specify the
|
|
|
|
|
# directory of external module to build. Setting M= takes precedence.
|
|
|
|
|
ifeq ("$(origin M)", "command line")
|
|
|
|
|
KBUILD_EXTMOD := $(M)
|
|
|
|
|
endif
|
|
|
|
|
|
2024-11-10 01:34:35 +00:00
|
|
|
ifeq ("$(origin MO)", "command line")
|
|
|
|
|
KBUILD_EXTMOD_OUTPUT := $(MO)
|
|
|
|
|
endif
|
|
|
|
|
|
2021-02-21 16:53:06 +00:00
|
|
|
$(if $(word 2, $(KBUILD_EXTMOD)), \
|
|
|
|
|
$(error building multiple external modules is not supported))
|
|
|
|
|
|
2022-07-14 05:02:42 +00:00
|
|
|
$(foreach x, % :, $(if $(findstring $x, $(KBUILD_EXTMOD)), \
|
|
|
|
|
$(error module directory path cannot contain '$x')))
|
|
|
|
|
|
2021-06-02 14:02:13 +00:00
|
|
|
# Remove trailing slashes
|
|
|
|
|
ifneq ($(filter %/, $(KBUILD_EXTMOD)),)
|
|
|
|
|
KBUILD_EXTMOD := $(shell dirname $(KBUILD_EXTMOD).)
|
|
|
|
|
endif
|
|
|
|
|
|
2021-02-21 16:53:06 +00:00
|
|
|
export KBUILD_EXTMOD
|
|
|
|
|
|
2023-11-23 09:05:40 +00:00
|
|
|
# backward compatibility
|
|
|
|
|
KBUILD_EXTRA_WARN ?= $(KBUILD_ENABLE_EXTRA_GCC_CHECKS)
|
|
|
|
|
|
|
|
|
|
ifeq ("$(origin W)", "command line")
|
|
|
|
|
KBUILD_EXTRA_WARN := $(W)
|
|
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
export KBUILD_EXTRA_WARN
|
|
|
|
|
|
2019-03-30 12:04:14 +00:00
|
|
|
# Kbuild will save output files in the current working directory.
|
|
|
|
|
# This does not need to match to the root of the kernel source tree.
|
|
|
|
|
#
|
|
|
|
|
# For example, you can do this:
|
|
|
|
|
#
|
|
|
|
|
# cd /dir/to/store/output/files; make -f /dir/to/kernel/source/Makefile
|
|
|
|
|
#
|
|
|
|
|
# If you want to save output files in a different location, there are
|
|
|
|
|
# two syntaxes to specify it.
|
|
|
|
|
#
|
2005-04-16 22:20:36 +00:00
|
|
|
# 1) O=
|
|
|
|
|
# Use "make O=dir/to/store/output/files/"
|
2006-06-24 22:07:55 +00:00
|
|
|
#
|
2005-04-16 22:20:36 +00:00
|
|
|
# 2) Set KBUILD_OUTPUT
|
2019-03-30 12:04:14 +00:00
|
|
|
# Set the environment variable KBUILD_OUTPUT to point to the output directory.
|
|
|
|
|
# export KBUILD_OUTPUT=dir/to/store/output/files/; make
|
2005-04-16 22:20:36 +00:00
|
|
|
#
|
|
|
|
|
# The O= assignment takes precedence over the KBUILD_OUTPUT environment
|
|
|
|
|
# variable.
|
|
|
|
|
|
2009-05-26 08:03:07 +00:00
|
|
|
ifeq ("$(origin O)", "command line")
|
|
|
|
|
KBUILD_OUTPUT := $(O)
|
2005-04-16 22:20:36 +00:00
|
|
|
endif
|
|
|
|
|
|
2024-11-10 01:34:33 +00:00
|
|
|
ifdef KBUILD_EXTMOD
|
|
|
|
|
ifdef KBUILD_OUTPUT
|
|
|
|
|
objtree := $(realpath $(KBUILD_OUTPUT))
|
|
|
|
|
$(if $(objtree),,$(error specified kernel directory "$(KBUILD_OUTPUT)" does not exist))
|
|
|
|
|
else
|
2024-11-10 01:34:39 +00:00
|
|
|
objtree := $(abs_srctree)
|
2024-11-10 01:34:33 +00:00
|
|
|
endif
|
2024-11-10 01:34:39 +00:00
|
|
|
# If Make is invoked from the kernel directory (either kernel
|
|
|
|
|
# source directory or kernel build directory), external modules
|
|
|
|
|
# are built in $(KBUILD_EXTMOD) for backward compatibility,
|
|
|
|
|
# otherwise, built in the current directory.
|
|
|
|
|
output := $(or $(KBUILD_EXTMOD_OUTPUT),$(if $(filter $(CURDIR),$(objtree) $(abs_srctree)),$(KBUILD_EXTMOD)))
|
2024-11-10 01:34:33 +00:00
|
|
|
# KBUILD_EXTMOD might be a relative path. Remember its absolute path before
|
|
|
|
|
# Make changes the working directory.
|
|
|
|
|
srcroot := $(realpath $(KBUILD_EXTMOD))
|
|
|
|
|
$(if $(srcroot),,$(error specified external module directory "$(KBUILD_EXTMOD)" does not exist))
|
|
|
|
|
else
|
|
|
|
|
objtree := .
|
|
|
|
|
output := $(KBUILD_OUTPUT)
|
|
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
export objtree srcroot
|
2024-11-10 01:34:32 +00:00
|
|
|
|
|
|
|
|
# Do we want to change the working directory?
|
|
|
|
|
ifneq ($(output),)
|
2023-12-15 16:06:37 +00:00
|
|
|
# $(realpath ...) gets empty if the path does not exist. Run 'mkdir -p' first.
|
2024-11-10 01:34:32 +00:00
|
|
|
$(shell mkdir -p "$(output)")
|
2019-03-30 12:04:14 +00:00
|
|
|
# $(realpath ...) resolves symlinks
|
2024-11-10 01:34:32 +00:00
|
|
|
abs_output := $(realpath $(output))
|
|
|
|
|
$(if $(abs_output),,$(error failed to create output directory "$(output)"))
|
|
|
|
|
endif
|
2019-03-30 12:04:14 +00:00
|
|
|
|
|
|
|
|
ifneq ($(words $(subst :, ,$(abs_srctree))), 1)
|
|
|
|
|
$(error source directory cannot contain spaces or colons)
|
|
|
|
|
endif
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2019-03-26 04:02:19 +00:00
|
|
|
export sub_make_done := 1
|
|
|
|
|
|
kbuild: revive "Entering directory" for Make >= 4.4.1
With commit 9da0763bdd82 ("kbuild: Use relative path when building in
a subdir of the source tree"), compiler messages in out-of-tree builds
include relative paths, which are relative to the build directory, not
the directory where make was started.
To help IDEs/editors find the source files, Kbuild lets GNU Make print
"Entering directory ..." when it changes the working directory. It has
been working fine for a long time, but David reported it is broken with
the latest GNU Make.
The behavior was changed by GNU Make commit 8f9e7722ff0f ("[SV 63537]
Fix setting -w in makefiles"). Previously, setting --no-print-directory
to MAKEFLAGS only affected child makes, but it is now interpreted in
the current make as soon as it is set.
[test code]
$ cat /tmp/Makefile
ifneq ($(SUBMAKE),1)
MAKEFLAGS += --no-print-directory
all: ; $(MAKE) SUBMAKE=1
else
all: ; :
endif
[before 8f9e7722ff0f]
$ make -C /tmp
make: Entering directory '/tmp'
make SUBMAKE=1
:
make: Leaving directory '/tmp'
[after 8f9e7722ff0f]
$ make -C /tmp
make SUBMAKE=1
:
Previously, the effect of --no-print-directory was delayed until Kbuild
started the directory descending, but it is no longer true with GNU Make
4.4.1.
This commit adds one more recursion to cater to GNU Make >= 4.4.1.
When Kbuild needs to change the working directory, __submake will be
executed twice.
__submake without --no-print-directory --> show "Entering directory ..."
__submake with --no-print-directory --> parse the rest of Makefile
We end up with one more recursion than needed for GNU Make < 4.4.1, but
I do not want to complicate the version check.
Reported-by: David Howells <dhowells@redhat.com>
Closes: https://lore.kernel.org/all/2427604.1686237298@warthog.procyon.org.uk/
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Tested-by: Nicolas Schier <n.schier@avm.de>
2023-06-26 23:30:13 +00:00
|
|
|
endif # sub_make_done
|
|
|
|
|
|
2024-11-10 01:34:31 +00:00
|
|
|
ifeq ($(abs_output),$(CURDIR))
|
kbuild: revive "Entering directory" for Make >= 4.4.1
With commit 9da0763bdd82 ("kbuild: Use relative path when building in
a subdir of the source tree"), compiler messages in out-of-tree builds
include relative paths, which are relative to the build directory, not
the directory where make was started.
To help IDEs/editors find the source files, Kbuild lets GNU Make print
"Entering directory ..." when it changes the working directory. It has
been working fine for a long time, but David reported it is broken with
the latest GNU Make.
The behavior was changed by GNU Make commit 8f9e7722ff0f ("[SV 63537]
Fix setting -w in makefiles"). Previously, setting --no-print-directory
to MAKEFLAGS only affected child makes, but it is now interpreted in
the current make as soon as it is set.
[test code]
$ cat /tmp/Makefile
ifneq ($(SUBMAKE),1)
MAKEFLAGS += --no-print-directory
all: ; $(MAKE) SUBMAKE=1
else
all: ; :
endif
[before 8f9e7722ff0f]
$ make -C /tmp
make: Entering directory '/tmp'
make SUBMAKE=1
:
make: Leaving directory '/tmp'
[after 8f9e7722ff0f]
$ make -C /tmp
make SUBMAKE=1
:
Previously, the effect of --no-print-directory was delayed until Kbuild
started the directory descending, but it is no longer true with GNU Make
4.4.1.
This commit adds one more recursion to cater to GNU Make >= 4.4.1.
When Kbuild needs to change the working directory, __submake will be
executed twice.
__submake without --no-print-directory --> show "Entering directory ..."
__submake with --no-print-directory --> parse the rest of Makefile
We end up with one more recursion than needed for GNU Make < 4.4.1, but
I do not want to complicate the version check.
Reported-by: David Howells <dhowells@redhat.com>
Closes: https://lore.kernel.org/all/2427604.1686237298@warthog.procyon.org.uk/
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Tested-by: Nicolas Schier <n.schier@avm.de>
2023-06-26 23:30:13 +00:00
|
|
|
# Suppress "Entering directory ..." if we are at the final work directory.
|
|
|
|
|
no-print-directory := --no-print-directory
|
|
|
|
|
else
|
|
|
|
|
# Recursion to show "Entering directory ..."
|
|
|
|
|
need-sub-make := 1
|
|
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
ifeq ($(filter --no-print-directory, $(MAKEFLAGS)),)
|
|
|
|
|
# If --no-print-directory is unset, recurse once again to set it.
|
|
|
|
|
# You may end up recursing into __sub-make twice. This is needed due to the
|
|
|
|
|
# behavior change in GNU Make 4.4.1.
|
|
|
|
|
need-sub-make := 1
|
|
|
|
|
endif
|
|
|
|
|
|
2019-03-19 04:02:36 +00:00
|
|
|
ifeq ($(need-sub-make),1)
|
|
|
|
|
|
2020-05-11 03:50:13 +00:00
|
|
|
PHONY += $(MAKECMDGOALS) __sub-make
|
2007-09-21 23:09:02 +00:00
|
|
|
|
2020-05-11 03:50:13 +00:00
|
|
|
$(filter-out $(this-makefile), $(MAKECMDGOALS)) __all: __sub-make
|
2012-10-15 12:49:12 +00:00
|
|
|
@:
|
2007-09-21 23:09:02 +00:00
|
|
|
|
2017-06-30 02:45:43 +00:00
|
|
|
# Invoke a second make in the output directory, passing relevant variables
|
2020-05-11 03:50:13 +00:00
|
|
|
__sub-make:
|
2024-11-10 01:34:31 +00:00
|
|
|
$(Q)$(MAKE) $(no-print-directory) -C $(abs_output) \
|
kbuild: revive "Entering directory" for Make >= 4.4.1
With commit 9da0763bdd82 ("kbuild: Use relative path when building in
a subdir of the source tree"), compiler messages in out-of-tree builds
include relative paths, which are relative to the build directory, not
the directory where make was started.
To help IDEs/editors find the source files, Kbuild lets GNU Make print
"Entering directory ..." when it changes the working directory. It has
been working fine for a long time, but David reported it is broken with
the latest GNU Make.
The behavior was changed by GNU Make commit 8f9e7722ff0f ("[SV 63537]
Fix setting -w in makefiles"). Previously, setting --no-print-directory
to MAKEFLAGS only affected child makes, but it is now interpreted in
the current make as soon as it is set.
[test code]
$ cat /tmp/Makefile
ifneq ($(SUBMAKE),1)
MAKEFLAGS += --no-print-directory
all: ; $(MAKE) SUBMAKE=1
else
all: ; :
endif
[before 8f9e7722ff0f]
$ make -C /tmp
make: Entering directory '/tmp'
make SUBMAKE=1
:
make: Leaving directory '/tmp'
[after 8f9e7722ff0f]
$ make -C /tmp
make SUBMAKE=1
:
Previously, the effect of --no-print-directory was delayed until Kbuild
started the directory descending, but it is no longer true with GNU Make
4.4.1.
This commit adds one more recursion to cater to GNU Make >= 4.4.1.
When Kbuild needs to change the working directory, __submake will be
executed twice.
__submake without --no-print-directory --> show "Entering directory ..."
__submake with --no-print-directory --> parse the rest of Makefile
We end up with one more recursion than needed for GNU Make < 4.4.1, but
I do not want to complicate the version check.
Reported-by: David Howells <dhowells@redhat.com>
Closes: https://lore.kernel.org/all/2427604.1686237298@warthog.procyon.org.uk/
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Tested-by: Nicolas Schier <n.schier@avm.de>
2023-06-26 23:30:13 +00:00
|
|
|
-f $(abs_srctree)/Makefile $(MAKECMDGOALS)
|
2005-04-16 22:20:36 +00:00
|
|
|
|
kbuild: revive "Entering directory" for Make >= 4.4.1
With commit 9da0763bdd82 ("kbuild: Use relative path when building in
a subdir of the source tree"), compiler messages in out-of-tree builds
include relative paths, which are relative to the build directory, not
the directory where make was started.
To help IDEs/editors find the source files, Kbuild lets GNU Make print
"Entering directory ..." when it changes the working directory. It has
been working fine for a long time, but David reported it is broken with
the latest GNU Make.
The behavior was changed by GNU Make commit 8f9e7722ff0f ("[SV 63537]
Fix setting -w in makefiles"). Previously, setting --no-print-directory
to MAKEFLAGS only affected child makes, but it is now interpreted in
the current make as soon as it is set.
[test code]
$ cat /tmp/Makefile
ifneq ($(SUBMAKE),1)
MAKEFLAGS += --no-print-directory
all: ; $(MAKE) SUBMAKE=1
else
all: ; :
endif
[before 8f9e7722ff0f]
$ make -C /tmp
make: Entering directory '/tmp'
make SUBMAKE=1
:
make: Leaving directory '/tmp'
[after 8f9e7722ff0f]
$ make -C /tmp
make SUBMAKE=1
:
Previously, the effect of --no-print-directory was delayed until Kbuild
started the directory descending, but it is no longer true with GNU Make
4.4.1.
This commit adds one more recursion to cater to GNU Make >= 4.4.1.
When Kbuild needs to change the working directory, __submake will be
executed twice.
__submake without --no-print-directory --> show "Entering directory ..."
__submake with --no-print-directory --> parse the rest of Makefile
We end up with one more recursion than needed for GNU Make < 4.4.1, but
I do not want to complicate the version check.
Reported-by: David Howells <dhowells@redhat.com>
Closes: https://lore.kernel.org/all/2427604.1686237298@warthog.procyon.org.uk/
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Tested-by: Nicolas Schier <n.schier@avm.de>
2023-06-26 23:30:13 +00:00
|
|
|
else # need-sub-make
|
2019-03-19 04:02:36 +00:00
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
# We process the rest of the Makefile if this is the final invocation of make
|
2014-09-09 11:02:22 +00:00
|
|
|
|
2024-11-10 01:34:33 +00:00
|
|
|
ifndef KBUILD_EXTMOD
|
|
|
|
|
srcroot := $(abs_srctree)
|
2014-04-25 21:25:18 +00:00
|
|
|
endif
|
2017-10-04 03:56:06 +00:00
|
|
|
|
2024-11-10 01:34:33 +00:00
|
|
|
ifeq ($(srcroot),$(CURDIR))
|
|
|
|
|
building_out_of_srctree :=
|
|
|
|
|
else
|
|
|
|
|
export building_out_of_srctree := 1
|
2019-07-06 03:07:13 +00:00
|
|
|
endif
|
2017-10-04 03:56:06 +00:00
|
|
|
|
2024-11-10 01:34:33 +00:00
|
|
|
ifdef KBUILD_ABS_SRCTREE
|
|
|
|
|
# Do nothing. Use the absolute path.
|
|
|
|
|
else ifeq ($(srcroot),$(CURDIR))
|
|
|
|
|
# Building in the source.
|
|
|
|
|
srcroot := .
|
|
|
|
|
else ifeq ($(srcroot)/,$(dir $(CURDIR)))
|
|
|
|
|
# Building in a subdirectory of the source.
|
|
|
|
|
srcroot := ..
|
|
|
|
|
endif
|
kbuild: use $(src) instead of $(srctree)/$(src) for source directory
Kbuild conventionally uses $(obj)/ for generated files, and $(src)/ for
checked-in source files. It is merely a convention without any functional
difference. In fact, $(obj) and $(src) are exactly the same, as defined
in scripts/Makefile.build:
src := $(obj)
When the kernel is built in a separate output directory, $(src) does
not accurately reflect the source directory location. While Kbuild
resolves this discrepancy by specifying VPATH=$(srctree) to search for
source files, it does not cover all cases. For example, when adding a
header search path for local headers, -I$(srctree)/$(src) is typically
passed to the compiler.
This introduces inconsistency between upstream and downstream Makefiles
because $(src) is used instead of $(srctree)/$(src) for the latter.
To address this inconsistency, this commit changes the semantics of
$(src) so that it always points to the directory in the source tree.
Going forward, the variables used in Makefiles will have the following
meanings:
$(obj) - directory in the object tree
$(src) - directory in the source tree (changed by this commit)
$(objtree) - the top of the kernel object tree
$(srctree) - the top of the kernel source tree
Consequently, $(srctree)/$(src) in upstream Makefiles need to be replaced
with $(src).
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
2024-04-27 14:55:02 +00:00
|
|
|
|
2024-11-10 01:34:33 +00:00
|
|
|
export srctree := $(if $(KBUILD_EXTMOD),$(abs_srctree),$(srcroot))
|
kbuild: use $(src) instead of $(srctree)/$(src) for source directory
Kbuild conventionally uses $(obj)/ for generated files, and $(src)/ for
checked-in source files. It is merely a convention without any functional
difference. In fact, $(obj) and $(src) are exactly the same, as defined
in scripts/Makefile.build:
src := $(obj)
When the kernel is built in a separate output directory, $(src) does
not accurately reflect the source directory location. While Kbuild
resolves this discrepancy by specifying VPATH=$(srctree) to search for
source files, it does not cover all cases. For example, when adding a
header search path for local headers, -I$(srctree)/$(src) is typically
passed to the compiler.
This introduces inconsistency between upstream and downstream Makefiles
because $(src) is used instead of $(srctree)/$(src) for the latter.
To address this inconsistency, this commit changes the semantics of
$(src) so that it always points to the directory in the source tree.
Going forward, the variables used in Makefiles will have the following
meanings:
$(obj) - directory in the object tree
$(src) - directory in the source tree (changed by this commit)
$(objtree) - the top of the kernel object tree
$(srctree) - the top of the kernel source tree
Consequently, $(srctree)/$(src) in upstream Makefiles need to be replaced
with $(src).
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
2024-04-27 14:55:02 +00:00
|
|
|
|
|
|
|
|
ifdef building_out_of_srctree
|
2024-11-10 01:34:33 +00:00
|
|
|
export VPATH := $(srcroot)
|
|
|
|
|
else
|
|
|
|
|
VPATH :=
|
kbuild: use $(src) instead of $(srctree)/$(src) for source directory
Kbuild conventionally uses $(obj)/ for generated files, and $(src)/ for
checked-in source files. It is merely a convention without any functional
difference. In fact, $(obj) and $(src) are exactly the same, as defined
in scripts/Makefile.build:
src := $(obj)
When the kernel is built in a separate output directory, $(src) does
not accurately reflect the source directory location. While Kbuild
resolves this discrepancy by specifying VPATH=$(srctree) to search for
source files, it does not cover all cases. For example, when adding a
header search path for local headers, -I$(srctree)/$(src) is typically
passed to the compiler.
This introduces inconsistency between upstream and downstream Makefiles
because $(src) is used instead of $(srctree)/$(src) for the latter.
To address this inconsistency, this commit changes the semantics of
$(src) so that it always points to the directory in the source tree.
Going forward, the variables used in Makefiles will have the following
meanings:
$(obj) - directory in the object tree
$(src) - directory in the source tree (changed by this commit)
$(objtree) - the top of the kernel object tree
$(srctree) - the top of the kernel source tree
Consequently, $(srctree)/$(src) in upstream Makefiles need to be replaced
with $(src).
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
2024-04-27 14:55:02 +00:00
|
|
|
endif
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2017-10-04 03:56:06 +00:00
|
|
|
# To make sure we do not include .config for any of the *config targets
|
|
|
|
|
# catch them early, and hand them over to scripts/kconfig/Makefile
|
|
|
|
|
# It is allowed to specify more targets when calling make, including
|
|
|
|
|
# mixing *config targets and build targets.
|
|
|
|
|
# For example 'make oldconfig all'.
|
|
|
|
|
# Detect when mixed targets is specified, and make a second invocation
|
|
|
|
|
# of make so .config is not included in this case either (for *config).
|
|
|
|
|
|
|
|
|
|
version_h := include/generated/uapi/linux/version.h
|
|
|
|
|
|
2018-02-11 08:40:29 +00:00
|
|
|
clean-targets := %clean mrproper cleandocs
|
|
|
|
|
no-dot-config-targets := $(clean-targets) \
|
2017-10-04 03:56:06 +00:00
|
|
|
cscope gtags TAGS tags help% %docs check% coccicheck \
|
kbuild: add 'headers' target to build up uapi headers in usr/include
In Linux build system, build targets and installation targets are
separated.
Examples are:
- 'make vmlinux' -> 'make install'
- 'make modules' -> 'make modules_install'
- 'make dtbs' -> 'make dtbs_install'
- 'make vdso' -> 'make vdso_install'
The intention is to run the build targets under the normal privilege,
then the installation targets under the root privilege since we need
the write permission to the system directories.
We have 'make headers_install' but the corresponding 'make headers'
stage does not exist. The purpose of headers_install is to provide
the kernel interface to C library. So, nobody would try to install
headers to /usr/include directly.
If 'sudo make INSTALL_HDR_PATH=/usr/include headers_install' were run,
some build artifacts in the kernel tree would be owned by root because
some of uapi headers are generated by 'uapi-asm-generic', 'archheaders'
targets.
Anyway, I believe it makes sense to split the header installation into
two stages.
[1] 'make headers'
Process headers in uapi directories by scripts/headers_install.sh
and copy them to usr/include
[2] 'make headers_install'
Copy '*.h' verbatim from usr/include to $(INSTALL_HDR_PATH)/include
For the backward compatibility, 'headers_install' depends on 'headers'.
Some samples expect uapi headers in usr/include. So, the 'headers'
target is useful to build up them in the fixed location usr/include
irrespective of INSTALL_HDR_PATH.
Another benefit is to stop polluting the final destination with the
time-stamp files '.install' and '.check'. Maybe you can see them in
your toolchains.
Lastly, my main motivation is to prepare for compile-testing uapi
headers. To build something, we have to save an object and .*.cmd
somewhere. The usr/include/ will be the work directory for that.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-06-04 10:14:02 +00:00
|
|
|
$(version_h) headers headers_% archheaders archscripts \
|
2020-03-26 19:29:33 +00:00
|
|
|
%asm-generic kernelversion %src-pkg dt_binding_check \
|
2023-03-15 15:50:18 +00:00
|
|
|
outputmakefile rustavailable rustfmt rustfmtcheck
|
2023-08-23 11:50:42 +00:00
|
|
|
no-sync-config-targets := $(no-dot-config-targets) %install modules_sign kernelrelease \
|
2021-02-28 06:10:25 +00:00
|
|
|
image_name
|
2024-11-11 17:17:41 +00:00
|
|
|
single-targets := %.a %.i %.ko %.lds %.ll %.lst %.mod %.o %.rsi %.s %/
|
2017-10-04 03:56:06 +00:00
|
|
|
|
2019-08-10 15:53:03 +00:00
|
|
|
config-build :=
|
|
|
|
|
mixed-build :=
|
|
|
|
|
need-config := 1
|
|
|
|
|
may-sync-config := 1
|
kbuild: make single targets work more correctly
Currently, the single target build directly descends into the directory
of the target. For example,
$ make foo/bar/baz.o
... directly descends into foo/bar/.
On the other hand, the normal build usually descends one directory at
a time, i.e. descends into foo/, and then foo/bar/.
This difference causes some problems.
[1] miss subdir-asflags-y, subdir-ccflags-y in upper Makefiles
The options in subdir-{as,cc}flags-y take effect in the current
and its sub-directories. In other words, they are inherited
downward. In the example above, the single target will miss
subdir-{as,cc}flags-y if they are defined in foo/Makefile.
[2] could be built in a different directory
As Documentation/kbuild/modules.rst section 4.3 says, Kbuild can
handle files that are spread over several sub-directories.
The build rule of foo/bar/baz.o may not necessarily be specified in
foo/bar/Makefile. It might be specifies in foo/Makefile as follows:
[foo/Makefile]
obj-y := bar/baz.o
This often happens when a module is so big that its source files
are divided into sub-directories.
In this case, there is no Makefile in the foo/bar/ directory, yet
the single target descends into foo/bar/, then fails due to the
missing Makefile. You can still do 'make foo/bar/' for partial
building, but cannot do 'make foo/bar/baz.s'. I believe the single
target '%.s' is a useful feature for inspecting the compiler output.
Some modules work around this issue by putting an empty Makefile
in every sub-directory.
This commit fixes those problems by making the single target build
descend in the same way as the normal build does.
Another change is the single target build will observe the CONFIG
options. Previously, it allowed users to build the foo.o even when
the corresponding CONFIG_FOO is disabled:
obj-$(CONFIG_FOO) += foo.o
In the new behavior, the single target build will just fail and show
"No rule to make target ..." (or "Nothing to be done for ..." if the
stale object already exists, but cannot be updated).
The disadvantage of this commit is the build speed. Now that the
single target build visits every directory and parses lots of
Makefiles, it is slower than before. (But, I hope it will not be
too slow.)
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-08-14 15:19:18 +00:00
|
|
|
single-build :=
|
2017-10-04 03:56:06 +00:00
|
|
|
|
|
|
|
|
ifneq ($(filter $(no-dot-config-targets), $(MAKECMDGOALS)),)
|
2024-02-02 01:31:42 +00:00
|
|
|
ifeq ($(filter-out $(no-dot-config-targets), $(MAKECMDGOALS)),)
|
2024-03-01 11:21:07 +00:00
|
|
|
need-config :=
|
2024-02-02 01:31:42 +00:00
|
|
|
endif
|
2017-10-04 03:56:06 +00:00
|
|
|
endif
|
|
|
|
|
|
kbuild: do not update config when running install targets
"make syncconfig" is automatically invoked when any of the following
happens:
- .config is updated
- any of Kconfig files is updated
- any of environment variables referenced in Kconfig is changed
Then, it updates configuration files such as include/config/auto.conf
include/generated/autoconf.h, etc.
Even install targets (install, modules_install, etc.) are no exception.
However, they should never ever modify the source tree. Install
targets are often run with root privileges. Once those configuration
files are owned by root, "make mrproper" would end up with permission
error.
Install targets should just copy things blindly. They should not care
whether the configuration is up-to-date or not. This makes more sense
because we are interested in the configuration that was used in the
previous kernel building.
This issue has existed since before, but rarely happened. I expect
more chance where people are hit by this; with the new Kconfig syntax
extension, the .config now contains the compiler information. If you
cross-compile the kernel with CROSS_COMPILE, but forget to pass it
for "make install", you meet "any of environment variables referenced
in Kconfig is changed" because $(CC) is referenced in Kconfig.
Another scenario is the compiler upgrade before the installation.
Install targets need the configuration. "make modules_install" refer
to CONFIG_MODULES etc. "make dtbs_install" also needs CONFIG_ARCH_*
to decide which dtb files to install. However, the auto-update of
the configuration files should be avoided. We already do this for
external modules.
Now, Make targets are categorized into 3 groups:
[1] Do not need the kernel configuration at all
help, coccicheck, headers_install etc.
[2] Need the latest kernel configuration
If new config options are added, Kconfig will show prompt to
ask user's selection.
Build targets such as vmlinux, in-kernel modules are the cases.
[3] Need the kernel configuration, but do not want to update it
Install targets except headers_install, and external modules
are the cases.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-07-20 07:46:34 +00:00
|
|
|
ifneq ($(filter $(no-sync-config-targets), $(MAKECMDGOALS)),)
|
2024-02-02 01:31:42 +00:00
|
|
|
ifeq ($(filter-out $(no-sync-config-targets), $(MAKECMDGOALS)),)
|
2024-03-01 11:21:07 +00:00
|
|
|
may-sync-config :=
|
2024-02-02 01:31:42 +00:00
|
|
|
endif
|
kbuild: do not update config when running install targets
"make syncconfig" is automatically invoked when any of the following
happens:
- .config is updated
- any of Kconfig files is updated
- any of environment variables referenced in Kconfig is changed
Then, it updates configuration files such as include/config/auto.conf
include/generated/autoconf.h, etc.
Even install targets (install, modules_install, etc.) are no exception.
However, they should never ever modify the source tree. Install
targets are often run with root privileges. Once those configuration
files are owned by root, "make mrproper" would end up with permission
error.
Install targets should just copy things blindly. They should not care
whether the configuration is up-to-date or not. This makes more sense
because we are interested in the configuration that was used in the
previous kernel building.
This issue has existed since before, but rarely happened. I expect
more chance where people are hit by this; with the new Kconfig syntax
extension, the .config now contains the compiler information. If you
cross-compile the kernel with CROSS_COMPILE, but forget to pass it
for "make install", you meet "any of environment variables referenced
in Kconfig is changed" because $(CC) is referenced in Kconfig.
Another scenario is the compiler upgrade before the installation.
Install targets need the configuration. "make modules_install" refer
to CONFIG_MODULES etc. "make dtbs_install" also needs CONFIG_ARCH_*
to decide which dtb files to install. However, the auto-update of
the configuration files should be avoided. We already do this for
external modules.
Now, Make targets are categorized into 3 groups:
[1] Do not need the kernel configuration at all
help, coccicheck, headers_install etc.
[2] Need the latest kernel configuration
If new config options are added, Kconfig will show prompt to
ask user's selection.
Build targets such as vmlinux, in-kernel modules are the cases.
[3] Need the kernel configuration, but do not want to update it
Install targets except headers_install, and external modules
are the cases.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-07-20 07:46:34 +00:00
|
|
|
endif
|
|
|
|
|
|
2023-10-14 10:54:36 +00:00
|
|
|
need-compiler := $(may-sync-config)
|
|
|
|
|
|
kbuild: do not update config when running install targets
"make syncconfig" is automatically invoked when any of the following
happens:
- .config is updated
- any of Kconfig files is updated
- any of environment variables referenced in Kconfig is changed
Then, it updates configuration files such as include/config/auto.conf
include/generated/autoconf.h, etc.
Even install targets (install, modules_install, etc.) are no exception.
However, they should never ever modify the source tree. Install
targets are often run with root privileges. Once those configuration
files are owned by root, "make mrproper" would end up with permission
error.
Install targets should just copy things blindly. They should not care
whether the configuration is up-to-date or not. This makes more sense
because we are interested in the configuration that was used in the
previous kernel building.
This issue has existed since before, but rarely happened. I expect
more chance where people are hit by this; with the new Kconfig syntax
extension, the .config now contains the compiler information. If you
cross-compile the kernel with CROSS_COMPILE, but forget to pass it
for "make install", you meet "any of environment variables referenced
in Kconfig is changed" because $(CC) is referenced in Kconfig.
Another scenario is the compiler upgrade before the installation.
Install targets need the configuration. "make modules_install" refer
to CONFIG_MODULES etc. "make dtbs_install" also needs CONFIG_ARCH_*
to decide which dtb files to install. However, the auto-update of
the configuration files should be avoided. We already do this for
external modules.
Now, Make targets are categorized into 3 groups:
[1] Do not need the kernel configuration at all
help, coccicheck, headers_install etc.
[2] Need the latest kernel configuration
If new config options are added, Kconfig will show prompt to
ask user's selection.
Build targets such as vmlinux, in-kernel modules are the cases.
[3] Need the kernel configuration, but do not want to update it
Install targets except headers_install, and external modules
are the cases.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-07-20 07:46:34 +00:00
|
|
|
ifneq ($(KBUILD_EXTMOD),)
|
2024-03-01 11:21:07 +00:00
|
|
|
may-sync-config :=
|
kbuild: do not update config when running install targets
"make syncconfig" is automatically invoked when any of the following
happens:
- .config is updated
- any of Kconfig files is updated
- any of environment variables referenced in Kconfig is changed
Then, it updates configuration files such as include/config/auto.conf
include/generated/autoconf.h, etc.
Even install targets (install, modules_install, etc.) are no exception.
However, they should never ever modify the source tree. Install
targets are often run with root privileges. Once those configuration
files are owned by root, "make mrproper" would end up with permission
error.
Install targets should just copy things blindly. They should not care
whether the configuration is up-to-date or not. This makes more sense
because we are interested in the configuration that was used in the
previous kernel building.
This issue has existed since before, but rarely happened. I expect
more chance where people are hit by this; with the new Kconfig syntax
extension, the .config now contains the compiler information. If you
cross-compile the kernel with CROSS_COMPILE, but forget to pass it
for "make install", you meet "any of environment variables referenced
in Kconfig is changed" because $(CC) is referenced in Kconfig.
Another scenario is the compiler upgrade before the installation.
Install targets need the configuration. "make modules_install" refer
to CONFIG_MODULES etc. "make dtbs_install" also needs CONFIG_ARCH_*
to decide which dtb files to install. However, the auto-update of
the configuration files should be avoided. We already do this for
external modules.
Now, Make targets are categorized into 3 groups:
[1] Do not need the kernel configuration at all
help, coccicheck, headers_install etc.
[2] Need the latest kernel configuration
If new config options are added, Kconfig will show prompt to
ask user's selection.
Build targets such as vmlinux, in-kernel modules are the cases.
[3] Need the kernel configuration, but do not want to update it
Install targets except headers_install, and external modules
are the cases.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-07-20 07:46:34 +00:00
|
|
|
endif
|
|
|
|
|
|
2017-10-04 03:56:06 +00:00
|
|
|
ifeq ($(KBUILD_EXTMOD),)
|
2024-03-01 11:21:07 +00:00
|
|
|
ifneq ($(filter %config,$(MAKECMDGOALS)),)
|
|
|
|
|
config-build := 1
|
|
|
|
|
ifneq ($(words $(MAKECMDGOALS)),1)
|
|
|
|
|
mixed-build := 1
|
2017-10-04 03:56:06 +00:00
|
|
|
endif
|
2024-03-01 11:21:07 +00:00
|
|
|
endif
|
2017-10-04 03:56:06 +00:00
|
|
|
endif
|
2018-02-11 08:40:29 +00:00
|
|
|
|
kbuild: make single targets work more correctly
Currently, the single target build directly descends into the directory
of the target. For example,
$ make foo/bar/baz.o
... directly descends into foo/bar/.
On the other hand, the normal build usually descends one directory at
a time, i.e. descends into foo/, and then foo/bar/.
This difference causes some problems.
[1] miss subdir-asflags-y, subdir-ccflags-y in upper Makefiles
The options in subdir-{as,cc}flags-y take effect in the current
and its sub-directories. In other words, they are inherited
downward. In the example above, the single target will miss
subdir-{as,cc}flags-y if they are defined in foo/Makefile.
[2] could be built in a different directory
As Documentation/kbuild/modules.rst section 4.3 says, Kbuild can
handle files that are spread over several sub-directories.
The build rule of foo/bar/baz.o may not necessarily be specified in
foo/bar/Makefile. It might be specifies in foo/Makefile as follows:
[foo/Makefile]
obj-y := bar/baz.o
This often happens when a module is so big that its source files
are divided into sub-directories.
In this case, there is no Makefile in the foo/bar/ directory, yet
the single target descends into foo/bar/, then fails due to the
missing Makefile. You can still do 'make foo/bar/' for partial
building, but cannot do 'make foo/bar/baz.s'. I believe the single
target '%.s' is a useful feature for inspecting the compiler output.
Some modules work around this issue by putting an empty Makefile
in every sub-directory.
This commit fixes those problems by making the single target build
descend in the same way as the normal build does.
Another change is the single target build will observe the CONFIG
options. Previously, it allowed users to build the foo.o even when
the corresponding CONFIG_FOO is disabled:
obj-$(CONFIG_FOO) += foo.o
In the new behavior, the single target build will just fail and show
"No rule to make target ..." (or "Nothing to be done for ..." if the
stale object already exists, but cannot be updated).
The disadvantage of this commit is the build speed. Now that the
single target build visits every directory and parses lots of
Makefiles, it is slower than before. (But, I hope it will not be
too slow.)
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-08-14 15:19:18 +00:00
|
|
|
# We cannot build single targets and the others at the same time
|
|
|
|
|
ifneq ($(filter $(single-targets), $(MAKECMDGOALS)),)
|
2024-03-01 11:21:07 +00:00
|
|
|
single-build := 1
|
2024-02-02 01:31:42 +00:00
|
|
|
ifneq ($(filter-out $(single-targets), $(MAKECMDGOALS)),)
|
2024-03-01 11:21:07 +00:00
|
|
|
mixed-build := 1
|
2024-02-02 01:31:42 +00:00
|
|
|
endif
|
kbuild: make single targets work more correctly
Currently, the single target build directly descends into the directory
of the target. For example,
$ make foo/bar/baz.o
... directly descends into foo/bar/.
On the other hand, the normal build usually descends one directory at
a time, i.e. descends into foo/, and then foo/bar/.
This difference causes some problems.
[1] miss subdir-asflags-y, subdir-ccflags-y in upper Makefiles
The options in subdir-{as,cc}flags-y take effect in the current
and its sub-directories. In other words, they are inherited
downward. In the example above, the single target will miss
subdir-{as,cc}flags-y if they are defined in foo/Makefile.
[2] could be built in a different directory
As Documentation/kbuild/modules.rst section 4.3 says, Kbuild can
handle files that are spread over several sub-directories.
The build rule of foo/bar/baz.o may not necessarily be specified in
foo/bar/Makefile. It might be specifies in foo/Makefile as follows:
[foo/Makefile]
obj-y := bar/baz.o
This often happens when a module is so big that its source files
are divided into sub-directories.
In this case, there is no Makefile in the foo/bar/ directory, yet
the single target descends into foo/bar/, then fails due to the
missing Makefile. You can still do 'make foo/bar/' for partial
building, but cannot do 'make foo/bar/baz.s'. I believe the single
target '%.s' is a useful feature for inspecting the compiler output.
Some modules work around this issue by putting an empty Makefile
in every sub-directory.
This commit fixes those problems by making the single target build
descend in the same way as the normal build does.
Another change is the single target build will observe the CONFIG
options. Previously, it allowed users to build the foo.o even when
the corresponding CONFIG_FOO is disabled:
obj-$(CONFIG_FOO) += foo.o
In the new behavior, the single target build will just fail and show
"No rule to make target ..." (or "Nothing to be done for ..." if the
stale object already exists, but cannot be updated).
The disadvantage of this commit is the build speed. Now that the
single target build visits every directory and parses lots of
Makefiles, it is slower than before. (But, I hope it will not be
too slow.)
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-08-14 15:19:18 +00:00
|
|
|
endif
|
|
|
|
|
|
2018-02-11 08:40:29 +00:00
|
|
|
# For "make -j clean all", "make -j mrproper defconfig all", etc.
|
|
|
|
|
ifneq ($(filter $(clean-targets),$(MAKECMDGOALS)),)
|
2024-03-01 11:21:07 +00:00
|
|
|
ifneq ($(filter-out $(clean-targets),$(MAKECMDGOALS)),)
|
|
|
|
|
mixed-build := 1
|
|
|
|
|
endif
|
2018-02-11 08:40:29 +00:00
|
|
|
endif
|
|
|
|
|
|
2017-10-04 03:56:06 +00:00
|
|
|
# install and modules_install need also be processed one by one
|
|
|
|
|
ifneq ($(filter install,$(MAKECMDGOALS)),)
|
2024-03-01 11:21:07 +00:00
|
|
|
ifneq ($(filter modules_install,$(MAKECMDGOALS)),)
|
|
|
|
|
mixed-build := 1
|
|
|
|
|
endif
|
2017-10-04 03:56:06 +00:00
|
|
|
endif
|
|
|
|
|
|
2019-08-10 15:53:03 +00:00
|
|
|
ifdef mixed-build
|
2017-10-04 03:56:06 +00:00
|
|
|
# ===========================================================================
|
|
|
|
|
# We're called with mixed targets (*config and build targets).
|
|
|
|
|
# Handle them one by one.
|
|
|
|
|
|
|
|
|
|
PHONY += $(MAKECMDGOALS) __build_one_by_one
|
|
|
|
|
|
2020-05-11 03:50:13 +00:00
|
|
|
$(MAKECMDGOALS): __build_one_by_one
|
2017-10-04 03:56:06 +00:00
|
|
|
@:
|
|
|
|
|
|
|
|
|
|
__build_one_by_one:
|
|
|
|
|
$(Q)set -e; \
|
|
|
|
|
for i in $(MAKECMDGOALS); do \
|
|
|
|
|
$(MAKE) -f $(srctree)/Makefile $$i; \
|
|
|
|
|
done
|
|
|
|
|
|
2019-08-10 15:53:03 +00:00
|
|
|
else # !mixed-build
|
2017-10-04 03:56:06 +00:00
|
|
|
|
2021-02-28 06:10:26 +00:00
|
|
|
include $(srctree)/scripts/Kbuild.include
|
2017-10-04 03:56:06 +00:00
|
|
|
|
|
|
|
|
# Read KERNELRELEASE from include/config/kernel.release (if it exists)
|
2024-11-10 01:34:30 +00:00
|
|
|
KERNELRELEASE = $(call read-file, $(objtree)/include/config/kernel.release)
|
2017-10-04 03:56:06 +00:00
|
|
|
KERNELVERSION = $(VERSION)$(if $(PATCHLEVEL),.$(PATCHLEVEL)$(if $(SUBLEVEL),.$(SUBLEVEL)))$(EXTRAVERSION)
|
|
|
|
|
export VERSION PATCHLEVEL SUBLEVEL KERNELRELEASE KERNELVERSION
|
|
|
|
|
|
2021-02-28 06:10:26 +00:00
|
|
|
include $(srctree)/scripts/subarch.include
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
|
# Cross compiling and selecting different set of gcc/bin-utils
|
|
|
|
|
# ---------------------------------------------------------------------------
|
|
|
|
|
#
|
|
|
|
|
# When performing cross compilation for other architectures ARCH shall be set
|
|
|
|
|
# to the target architecture. (See arch/* for the possibilities).
|
|
|
|
|
# ARCH can be set during invocation of make:
|
2023-01-13 17:32:57 +00:00
|
|
|
# make ARCH=arm64
|
2005-04-16 22:20:36 +00:00
|
|
|
# Another way is to have ARCH set in the environment.
|
|
|
|
|
# The default ARCH is the host where make is executed.
|
|
|
|
|
|
|
|
|
|
# CROSS_COMPILE specify the prefix used for all executables used
|
|
|
|
|
# during compilation. Only gcc and related bin-utils executables
|
|
|
|
|
# are prefixed with $(CROSS_COMPILE).
|
|
|
|
|
# CROSS_COMPILE can be set on the command line
|
2023-01-13 17:32:57 +00:00
|
|
|
# make CROSS_COMPILE=aarch64-linux-gnu-
|
2005-04-16 22:20:36 +00:00
|
|
|
# Alternatively CROSS_COMPILE can be set in the environment.
|
|
|
|
|
# Default value for CROSS_COMPILE is not to prefix executables
|
|
|
|
|
# Note: Some architectures assign CROSS_COMPILE in their arch/*/Makefile
|
2009-10-11 21:22:58 +00:00
|
|
|
ARCH ?= $(SUBARCH)
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
|
# Architecture as present in compile.h
|
2007-10-11 09:11:36 +00:00
|
|
|
UTS_MACHINE := $(ARCH)
|
|
|
|
|
SRCARCH := $(ARCH)
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2007-11-12 19:14:19 +00:00
|
|
|
# Additional ARCH settings for x86
|
|
|
|
|
ifeq ($(ARCH),i386)
|
|
|
|
|
SRCARCH := x86
|
|
|
|
|
endif
|
|
|
|
|
ifeq ($(ARCH),x86_64)
|
|
|
|
|
SRCARCH := x86
|
|
|
|
|
endif
|
2007-10-25 17:42:04 +00:00
|
|
|
|
2008-12-03 07:17:12 +00:00
|
|
|
# Additional ARCH settings for sparc
|
2010-10-25 05:48:23 +00:00
|
|
|
ifeq ($(ARCH),sparc32)
|
|
|
|
|
SRCARCH := sparc
|
|
|
|
|
endif
|
2008-07-27 21:00:59 +00:00
|
|
|
ifeq ($(ARCH),sparc64)
|
2008-12-03 07:17:12 +00:00
|
|
|
SRCARCH := sparc
|
2008-07-27 21:00:59 +00:00
|
|
|
endif
|
2008-06-20 22:24:17 +00:00
|
|
|
|
2021-06-10 02:03:31 +00:00
|
|
|
# Additional ARCH settings for parisc
|
|
|
|
|
ifeq ($(ARCH),parisc64)
|
|
|
|
|
SRCARCH := parisc
|
|
|
|
|
endif
|
|
|
|
|
|
kconfig: use /boot/config-* etc. as DEFCONFIG_LIST only for native build
When the .config file is missing, 'make config', 'make menuconfig', etc.
uses a file listed in DEFCONFIG_LIST, if found, as base configuration.
Ususally, /boot/config-$(uname -r) exists, and is used as default.
However, when you are cross-compiling the kernel, it does not make
sense to use /boot/config-* on the build host. It should default to
arch/$(SRCARCH)/configs/$(KBUILD_DEFCONFIG).
UML previously did not use DEFCONFIG_LIST at all, but it should be
able to use arch/um/configs/$(KBUILD_DEFCONFIG) as a base config file.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2021-04-10 14:31:58 +00:00
|
|
|
export cross_compiling :=
|
|
|
|
|
ifneq ($(SRCARCH),$(SUBARCH))
|
|
|
|
|
cross_compiling := 1
|
|
|
|
|
endif
|
|
|
|
|
|
2006-06-09 05:12:51 +00:00
|
|
|
KCONFIG_CONFIG ?= .config
|
2010-12-14 16:39:44 +00:00
|
|
|
export KCONFIG_CONFIG
|
2006-06-09 05:12:51 +00:00
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
# SHELL used by kbuild
|
2019-08-25 13:28:37 +00:00
|
|
|
CONFIG_SHELL := sh
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2018-07-12 10:38:36 +00:00
|
|
|
HOST_LFS_CFLAGS := $(shell getconf LFS_CFLAGS 2>/dev/null)
|
|
|
|
|
HOST_LFS_LDFLAGS := $(shell getconf LFS_LDFLAGS 2>/dev/null)
|
|
|
|
|
HOST_LFS_LIBS := $(shell getconf LFS_LIBS 2>/dev/null)
|
2017-07-09 18:02:36 +00:00
|
|
|
|
2020-04-08 01:36:23 +00:00
|
|
|
ifneq ($(LLVM),)
|
kbuild: Make $(LLVM) more flexible
The LLVM make variable allows a developer to quickly switch between the
GNU and LLVM tools. However, it does not handle versioned binaries, such
as the ones shipped by Debian, as LLVM=1 just defines the tool variables
with the unversioned binaries.
There was some discussion during the review of the patch that introduces
LLVM=1 around versioned binaries, ultimately coming to the conclusion
that developers can just add the folder that contains the unversioned
binaries to their PATH, as Debian's versioned suffixed binaries are
really just symlinks to the unversioned binaries in /usr/lib/llvm-#/bin:
$ realpath /usr/bin/clang-14
/usr/lib/llvm-14/bin/clang
$ PATH=/usr/lib/llvm-14/bin:$PATH make ... LLVM=1
However, that can be cumbersome to developers who are constantly testing
series with different toolchains and versions. It is simple enough to
support these versioned binaries directly in the Kbuild system by
allowing the developer to specify the version suffix with LLVM=, which
is shorter than the above suggestion:
$ make ... LLVM=-14
It does not change the meaning of LLVM=1 (which will continue to use
unversioned binaries) and it does not add too much additional complexity
to the existing $(LLVM) code, while allowing developers to quickly test
their series with different versions of the whole LLVM suite of tools.
Some developers may build LLVM from source but not add the binaries to
their PATH, as they may not want to use that toolchain systemwide.
Support those developers by allowing them to supply the directory that
the LLVM tools are available in, as it is no more complex to support
than the version suffix change above.
$ make ... LLVM=/path/to/llvm/
Update and reorder the documentation to reflect these new additions.
At the same time, notate that LLVM=0 is not the same as just omitting it
altogether, which has confused people in the past.
Link: https://lore.kernel.org/r/20200317215515.226917-1-ndesaulniers@google.com/
Link: https://lore.kernel.org/r/20220224151322.072632223@infradead.org/
Suggested-by: Masahiro Yamada <masahiroy@kernel.org>
Suggested-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2022-03-04 17:08:14 +00:00
|
|
|
ifneq ($(filter %/,$(LLVM)),)
|
|
|
|
|
LLVM_PREFIX := $(LLVM)
|
|
|
|
|
else ifneq ($(filter -%,$(LLVM)),)
|
|
|
|
|
LLVM_SUFFIX := $(LLVM)
|
|
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
HOSTCC = $(LLVM_PREFIX)clang$(LLVM_SUFFIX)
|
|
|
|
|
HOSTCXX = $(LLVM_PREFIX)clang++$(LLVM_SUFFIX)
|
2020-04-08 01:36:23 +00:00
|
|
|
else
|
|
|
|
|
HOSTCC = gcc
|
|
|
|
|
HOSTCXX = g++
|
|
|
|
|
endif
|
2021-07-03 14:42:57 +00:00
|
|
|
HOSTRUSTC = rustc
|
2022-04-01 23:18:02 +00:00
|
|
|
HOSTPKG_CONFIG = pkg-config
|
kbuild: add infrastructure to build userspace programs
Kbuild supports the infrastructure to build host programs, but there
was no support to build userspace programs for the target architecture
(i.e. the same architecture as the kernel).
Sam Ravnborg worked on this in 2014 (https://lkml.org/lkml/2014/7/13/154),
but it was not merged. One problem at that time was, there was no good way
to know whether $(CC) can link standalone programs. In fact, pre-built
kernel.org toolchains [1] are often used for building the kernel, but they
do not provide libc.
Now, we can handle this cleanly because the compiler capability is
evaluated at the Kconfig time. If $(CC) cannot link standalone programs,
the relevant options are hidden by 'depends on CC_CAN_LINK'.
The implementation just mimics scripts/Makefile.host
The userspace programs are compiled with the same flags as the host
programs. In addition, it uses -m32 or -m64 if it is found in
$(KBUILD_CFLAGS).
This new syntax has two usecases.
- Sample programs
Several userspace programs under samples/ include UAPI headers
installed in usr/include. Most of them were previously built for
the host architecture just to use the 'hostprogs' syntax.
However, 'make headers' always works for the target architecture.
This caused the arch mismatch in cross-compiling. To fix this
distortion, sample code should be built for the target architecture.
- Bpfilter
net/bpfilter/Makefile compiles bpfilter_umh as the user mode helper,
and embeds it into the kernel. Currently, it overrides HOSTCC with
CC to use the 'hostprogs' syntax. This hack should go away.
[1]: https://mirrors.edge.kernel.org/pub/tools/crosstool/
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
2020-04-29 03:45:14 +00:00
|
|
|
|
2022-02-01 21:35:42 +00:00
|
|
|
KBUILD_USERHOSTCFLAGS := -Wall -Wmissing-prototypes -Wstrict-prototypes \
|
2023-06-09 09:28:30 +00:00
|
|
|
-O2 -fomit-frame-pointer -std=gnu11
|
2022-02-01 21:35:42 +00:00
|
|
|
KBUILD_USERCFLAGS := $(KBUILD_USERHOSTCFLAGS) $(USERCFLAGS)
|
|
|
|
|
KBUILD_USERLDFLAGS := $(USERLDFLAGS)
|
kbuild: add infrastructure to build userspace programs
Kbuild supports the infrastructure to build host programs, but there
was no support to build userspace programs for the target architecture
(i.e. the same architecture as the kernel).
Sam Ravnborg worked on this in 2014 (https://lkml.org/lkml/2014/7/13/154),
but it was not merged. One problem at that time was, there was no good way
to know whether $(CC) can link standalone programs. In fact, pre-built
kernel.org toolchains [1] are often used for building the kernel, but they
do not provide libc.
Now, we can handle this cleanly because the compiler capability is
evaluated at the Kconfig time. If $(CC) cannot link standalone programs,
the relevant options are hidden by 'depends on CC_CAN_LINK'.
The implementation just mimics scripts/Makefile.host
The userspace programs are compiled with the same flags as the host
programs. In addition, it uses -m32 or -m64 if it is found in
$(KBUILD_CFLAGS).
This new syntax has two usecases.
- Sample programs
Several userspace programs under samples/ include UAPI headers
installed in usr/include. Most of them were previously built for
the host architecture just to use the 'hostprogs' syntax.
However, 'make headers' always works for the target architecture.
This caused the arch mismatch in cross-compiling. To fix this
distortion, sample code should be built for the target architecture.
- Bpfilter
net/bpfilter/Makefile compiles bpfilter_umh as the user mode helper,
and embeds it into the kernel. Currently, it overrides HOSTCC with
CC to use the 'hostprogs' syntax. This hack should go away.
[1]: https://mirrors.edge.kernel.org/pub/tools/crosstool/
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
2020-04-29 03:45:14 +00:00
|
|
|
|
2021-07-03 14:42:57 +00:00
|
|
|
# These flags apply to all Rust code in the tree, including the kernel and
|
|
|
|
|
# host programs.
|
|
|
|
|
export rust_common_flags := --edition=2021 \
|
|
|
|
|
-Zbinary_dep_depinfo=y \
|
2024-08-27 10:04:03 +00:00
|
|
|
-Astable_features \
|
rust: relax most deny-level lints to warnings
Since we are starting to support several Rust toolchains, lints (including
Clippy ones) now may behave differently and lint groups may include
new lints.
Therefore, to maximize the chances a given version works, relax some
deny-level lints to warnings. It may also make our lives a bit easier
while developing new code or refactoring.
To be clear, the requirements for in-tree code are still the same, since
Rust code still needs to be warning-free (patches should be clean under
`WERROR=y`) and the set of lints is not changed.
`unsafe_op_in_unsafe_fn` is left unmodified, i.e. as an error, since it is
becoming the default in the language (warn-by-default in Rust 2024 [1] and
ideally an error later on) and thus it should also be very well tested. In
addition, it is simple enough that it should not have false positives
(unlike e.g. `rust_2018_idioms`'s `explicit_outlives_requirements`).
`non_ascii_idents` is left unmodified as well, i.e. as an error, since
it is unlikely one gains any productivity during development if it
were a warning (in fact, it may be worse, since it is likely one made
a typo). In addition, it should not have false positives.
Finally, put the two `-D` ones at the top and take the chance to do one
per line.
Link: https://github.com/rust-lang/rust/pull/112038 [1]
Reviewed-by: Finn Behrens <me@kloenk.dev>
Tested-by: Benno Lossin <benno.lossin@proton.me>
Tested-by: Andreas Hindborg <a.hindborg@samsung.com>
Link: https://lore.kernel.org/r/20240709160615.998336-5-ojeda@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-07-09 16:05:59 +00:00
|
|
|
-Dnon_ascii_idents \
|
2024-09-04 20:43:30 +00:00
|
|
|
-Dunsafe_op_in_unsafe_fn \
|
|
|
|
|
-Wmissing_docs \
|
rust: relax most deny-level lints to warnings
Since we are starting to support several Rust toolchains, lints (including
Clippy ones) now may behave differently and lint groups may include
new lints.
Therefore, to maximize the chances a given version works, relax some
deny-level lints to warnings. It may also make our lives a bit easier
while developing new code or refactoring.
To be clear, the requirements for in-tree code are still the same, since
Rust code still needs to be warning-free (patches should be clean under
`WERROR=y`) and the set of lints is not changed.
`unsafe_op_in_unsafe_fn` is left unmodified, i.e. as an error, since it is
becoming the default in the language (warn-by-default in Rust 2024 [1] and
ideally an error later on) and thus it should also be very well tested. In
addition, it is simple enough that it should not have false positives
(unlike e.g. `rust_2018_idioms`'s `explicit_outlives_requirements`).
`non_ascii_idents` is left unmodified as well, i.e. as an error, since
it is unlikely one gains any productivity during development if it
were a warning (in fact, it may be worse, since it is likely one made
a typo). In addition, it should not have false positives.
Finally, put the two `-D` ones at the top and take the chance to do one
per line.
Link: https://github.com/rust-lang/rust/pull/112038 [1]
Reviewed-by: Finn Behrens <me@kloenk.dev>
Tested-by: Benno Lossin <benno.lossin@proton.me>
Tested-by: Andreas Hindborg <a.hindborg@samsung.com>
Link: https://lore.kernel.org/r/20240709160615.998336-5-ojeda@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-07-09 16:05:59 +00:00
|
|
|
-Wrust_2018_idioms \
|
|
|
|
|
-Wunreachable_pub \
|
2024-07-09 16:06:00 +00:00
|
|
|
-Wclippy::all \
|
2024-09-04 20:43:35 +00:00
|
|
|
-Wclippy::ignored_unit_patterns \
|
2024-07-09 16:06:00 +00:00
|
|
|
-Wclippy::mut_mut \
|
rust: relax most deny-level lints to warnings
Since we are starting to support several Rust toolchains, lints (including
Clippy ones) now may behave differently and lint groups may include
new lints.
Therefore, to maximize the chances a given version works, relax some
deny-level lints to warnings. It may also make our lives a bit easier
while developing new code or refactoring.
To be clear, the requirements for in-tree code are still the same, since
Rust code still needs to be warning-free (patches should be clean under
`WERROR=y`) and the set of lints is not changed.
`unsafe_op_in_unsafe_fn` is left unmodified, i.e. as an error, since it is
becoming the default in the language (warn-by-default in Rust 2024 [1] and
ideally an error later on) and thus it should also be very well tested. In
addition, it is simple enough that it should not have false positives
(unlike e.g. `rust_2018_idioms`'s `explicit_outlives_requirements`).
`non_ascii_idents` is left unmodified as well, i.e. as an error, since
it is unlikely one gains any productivity during development if it
were a warning (in fact, it may be worse, since it is likely one made
a typo). In addition, it should not have false positives.
Finally, put the two `-D` ones at the top and take the chance to do one
per line.
Link: https://github.com/rust-lang/rust/pull/112038 [1]
Reviewed-by: Finn Behrens <me@kloenk.dev>
Tested-by: Benno Lossin <benno.lossin@proton.me>
Tested-by: Andreas Hindborg <a.hindborg@samsung.com>
Link: https://lore.kernel.org/r/20240709160615.998336-5-ojeda@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-07-09 16:05:59 +00:00
|
|
|
-Wclippy::needless_bitwise_bool \
|
|
|
|
|
-Wclippy::needless_continue \
|
rust: allow `clippy::needless_lifetimes`
In beta Clippy (i.e. Rust 1.83.0), the `needless_lifetimes` lint has
been extended [1] to suggest eliding `impl` lifetimes, e.g.
error: the following explicit lifetimes could be elided: 'a
--> rust/kernel/list.rs:647:6
|
647 | impl<'a, T: ?Sized + ListItem<ID>, const ID: u64> FusedIterator for Iter<'a, T, ID> {}
| ^^ ^^
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#needless_lifetimes
= note: `-D clippy::needless-lifetimes` implied by `-D warnings`
= help: to override `-D warnings` add `#[allow(clippy::needless_lifetimes)]`
help: elide the lifetimes
|
647 - impl<'a, T: ?Sized + ListItem<ID>, const ID: u64> FusedIterator for Iter<'a, T, ID> {}
647 + impl<T: ?Sized + ListItem<ID>, const ID: u64> FusedIterator for Iter<'_, T, ID> {}
A possibility would have been to clean them -- the RFC patch [2] did
this, while asking if we wanted these cleanups. There is an open issue
[3] in Clippy about being able to differentiate some of the new cases,
e.g. those that do not involve introducing `'_`. Thus it seems others
feel similarly.
Thus, for the time being, we decided to `allow` the lint.
Link: https://github.com/rust-lang/rust-clippy/pull/13286 [1]
Link: https://lore.kernel.org/rust-for-linux/20241012231300.397010-1-ojeda@kernel.org/ [2]
Link: https://github.com/rust-lang/rust-clippy/issues/13514 [3]
Reviewed-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Andreas Hindborg <a.hindborg@kernel.org>
Link: https://lore.kernel.org/r/20241116181538.369355-1-ojeda@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-11-16 18:15:37 +00:00
|
|
|
-Aclippy::needless_lifetimes \
|
rust: relax most deny-level lints to warnings
Since we are starting to support several Rust toolchains, lints (including
Clippy ones) now may behave differently and lint groups may include
new lints.
Therefore, to maximize the chances a given version works, relax some
deny-level lints to warnings. It may also make our lives a bit easier
while developing new code or refactoring.
To be clear, the requirements for in-tree code are still the same, since
Rust code still needs to be warning-free (patches should be clean under
`WERROR=y`) and the set of lints is not changed.
`unsafe_op_in_unsafe_fn` is left unmodified, i.e. as an error, since it is
becoming the default in the language (warn-by-default in Rust 2024 [1] and
ideally an error later on) and thus it should also be very well tested. In
addition, it is simple enough that it should not have false positives
(unlike e.g. `rust_2018_idioms`'s `explicit_outlives_requirements`).
`non_ascii_idents` is left unmodified as well, i.e. as an error, since
it is unlikely one gains any productivity during development if it
were a warning (in fact, it may be worse, since it is likely one made
a typo). In addition, it should not have false positives.
Finally, put the two `-D` ones at the top and take the chance to do one
per line.
Link: https://github.com/rust-lang/rust/pull/112038 [1]
Reviewed-by: Finn Behrens <me@kloenk.dev>
Tested-by: Benno Lossin <benno.lossin@proton.me>
Tested-by: Andreas Hindborg <a.hindborg@samsung.com>
Link: https://lore.kernel.org/r/20240709160615.998336-5-ojeda@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-07-09 16:05:59 +00:00
|
|
|
-Wclippy::no_mangle_with_rust_abi \
|
2024-09-04 20:43:32 +00:00
|
|
|
-Wclippy::undocumented_unsafe_blocks \
|
2024-09-04 20:43:33 +00:00
|
|
|
-Wclippy::unnecessary_safety_comment \
|
2024-09-04 20:43:34 +00:00
|
|
|
-Wclippy::unnecessary_safety_doc \
|
2024-09-04 20:43:36 +00:00
|
|
|
-Wrustdoc::missing_crate_level_docs \
|
|
|
|
|
-Wrustdoc::unescaped_backticks
|
2021-07-03 14:42:57 +00:00
|
|
|
|
2024-07-20 07:27:38 +00:00
|
|
|
KBUILD_HOSTCFLAGS := $(KBUILD_USERHOSTCFLAGS) $(HOST_LFS_CFLAGS) \
|
|
|
|
|
$(HOSTCFLAGS) -I $(srctree)/scripts/include
|
|
|
|
|
KBUILD_HOSTCXXFLAGS := -Wall -O2 $(HOST_LFS_CFLAGS) $(HOSTCXXFLAGS) \
|
|
|
|
|
-I $(srctree)/scripts/include
|
2021-07-03 14:42:57 +00:00
|
|
|
KBUILD_HOSTRUSTFLAGS := $(rust_common_flags) -O -Cstrip=debuginfo \
|
|
|
|
|
-Zallow-features= $(HOSTRUSTFLAGS)
|
2018-07-10 00:46:02 +00:00
|
|
|
KBUILD_HOSTLDFLAGS := $(HOST_LFS_LDFLAGS) $(HOSTLDFLAGS)
|
|
|
|
|
KBUILD_HOSTLDLIBS := $(HOST_LFS_LIBS) $(HOSTLDLIBS)
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
|
# Make variables (CC, etc...)
|
|
|
|
|
CPP = $(CC) -E
|
2020-04-08 01:36:23 +00:00
|
|
|
ifneq ($(LLVM),)
|
kbuild: Make $(LLVM) more flexible
The LLVM make variable allows a developer to quickly switch between the
GNU and LLVM tools. However, it does not handle versioned binaries, such
as the ones shipped by Debian, as LLVM=1 just defines the tool variables
with the unversioned binaries.
There was some discussion during the review of the patch that introduces
LLVM=1 around versioned binaries, ultimately coming to the conclusion
that developers can just add the folder that contains the unversioned
binaries to their PATH, as Debian's versioned suffixed binaries are
really just symlinks to the unversioned binaries in /usr/lib/llvm-#/bin:
$ realpath /usr/bin/clang-14
/usr/lib/llvm-14/bin/clang
$ PATH=/usr/lib/llvm-14/bin:$PATH make ... LLVM=1
However, that can be cumbersome to developers who are constantly testing
series with different toolchains and versions. It is simple enough to
support these versioned binaries directly in the Kbuild system by
allowing the developer to specify the version suffix with LLVM=, which
is shorter than the above suggestion:
$ make ... LLVM=-14
It does not change the meaning of LLVM=1 (which will continue to use
unversioned binaries) and it does not add too much additional complexity
to the existing $(LLVM) code, while allowing developers to quickly test
their series with different versions of the whole LLVM suite of tools.
Some developers may build LLVM from source but not add the binaries to
their PATH, as they may not want to use that toolchain systemwide.
Support those developers by allowing them to supply the directory that
the LLVM tools are available in, as it is no more complex to support
than the version suffix change above.
$ make ... LLVM=/path/to/llvm/
Update and reorder the documentation to reflect these new additions.
At the same time, notate that LLVM=0 is not the same as just omitting it
altogether, which has confused people in the past.
Link: https://lore.kernel.org/r/20200317215515.226917-1-ndesaulniers@google.com/
Link: https://lore.kernel.org/r/20220224151322.072632223@infradead.org/
Suggested-by: Masahiro Yamada <masahiroy@kernel.org>
Suggested-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2022-03-04 17:08:14 +00:00
|
|
|
CC = $(LLVM_PREFIX)clang$(LLVM_SUFFIX)
|
|
|
|
|
LD = $(LLVM_PREFIX)ld.lld$(LLVM_SUFFIX)
|
|
|
|
|
AR = $(LLVM_PREFIX)llvm-ar$(LLVM_SUFFIX)
|
|
|
|
|
NM = $(LLVM_PREFIX)llvm-nm$(LLVM_SUFFIX)
|
|
|
|
|
OBJCOPY = $(LLVM_PREFIX)llvm-objcopy$(LLVM_SUFFIX)
|
|
|
|
|
OBJDUMP = $(LLVM_PREFIX)llvm-objdump$(LLVM_SUFFIX)
|
|
|
|
|
READELF = $(LLVM_PREFIX)llvm-readelf$(LLVM_SUFFIX)
|
|
|
|
|
STRIP = $(LLVM_PREFIX)llvm-strip$(LLVM_SUFFIX)
|
2020-04-08 01:36:23 +00:00
|
|
|
else
|
|
|
|
|
CC = $(CROSS_COMPILE)gcc
|
|
|
|
|
LD = $(CROSS_COMPILE)ld
|
2005-04-16 22:20:36 +00:00
|
|
|
AR = $(CROSS_COMPILE)ar
|
|
|
|
|
NM = $(CROSS_COMPILE)nm
|
|
|
|
|
OBJCOPY = $(CROSS_COMPILE)objcopy
|
|
|
|
|
OBJDUMP = $(CROSS_COMPILE)objdump
|
2019-12-04 22:54:41 +00:00
|
|
|
READELF = $(CROSS_COMPILE)readelf
|
2020-04-08 01:36:23 +00:00
|
|
|
STRIP = $(CROSS_COMPILE)strip
|
|
|
|
|
endif
|
2021-07-03 14:42:57 +00:00
|
|
|
RUSTC = rustc
|
|
|
|
|
RUSTDOC = rustdoc
|
|
|
|
|
RUSTFMT = rustfmt
|
|
|
|
|
CLIPPY_DRIVER = clippy-driver
|
|
|
|
|
BINDGEN = bindgen
|
kbuild: add ability to generate BTF type info for vmlinux
This patch adds new config option to trigger generation of BTF type
information from DWARF debuginfo for vmlinux and kernel modules through
pahole, which in turn relies on libbpf for btf_dedup() algorithm.
The intent is to record compact type information of all types used
inside kernel, including all the structs/unions/typedefs/etc. This
enables BPF's compile-once-run-everywhere ([0]) approach, in which
tracing programs that are inspecting kernel's internal data (e.g.,
struct task_struct) can be compiled on a system running some kernel
version, but would be possible to run on other kernel versions (and
configurations) without recompilation, even if the layout of structs
changed and/or some of the fields were added, removed, or renamed.
This is only possible if BPF loader can get kernel type info to adjust
all the offsets correctly. This patch is a first time in this direction,
making sure that BTF type info is part of Linux kernel image in
non-loadable ELF section.
BTF deduplication ([1]) algorithm typically provides 100x savings
compared to DWARF data, so resulting .BTF section is not big as is
typically about 2MB in size.
[0] http://vger.kernel.org/lpc-bpf2018.html#session-2
[1] https://facebookmicrosites.github.io/bpf/blog/2018/11/14/btf-enhancement.html
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>
Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
Cc: Daniel Borkmann <daniel@iogearbox.net>
Cc: Alexei Starovoitov <ast@fb.com>
Cc: Yonghong Song <yhs@fb.com>
Cc: Martin KaFai Lau <kafai@fb.com>
Signed-off-by: Andrii Nakryiko <andriin@fb.com>
Acked-by: David S. Miller <davem@davemloft.net>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
2019-04-02 16:49:50 +00:00
|
|
|
PAHOLE = pahole
|
2020-07-11 21:53:24 +00:00
|
|
|
RESOLVE_BTFIDS = $(objtree)/tools/bpf/resolve_btfids/resolve_btfids
|
2017-12-09 16:02:28 +00:00
|
|
|
LEX = flex
|
|
|
|
|
YACC = bison
|
2005-04-16 22:20:36 +00:00
|
|
|
AWK = awk
|
2009-07-20 19:37:11 +00:00
|
|
|
INSTALLKERNEL := installkernel
|
2005-04-16 22:20:36 +00:00
|
|
|
PERL = perl
|
kbuild: add PYTHON2 and PYTHON3 variables
The variable 'PYTHON' allows users to specify a proper executable
name in case the default 'python' does not work. However, this does
not address the case where both Python 2.x and 3.x scripts are used
in one source tree.
PEP 394 (https://www.python.org/dev/peps/pep-0394/) provides a
convention for Python scripts portability. Here is a quotation:
In order to tolerate differences across platforms, all new code
that needs to invoke the Python interpreter should not specify
'python', but rather should specify either 'python2' or 'python3'.
This distinction should be made in shebangs, when invoking from a
shell script, when invoking via the system() call, or when invoking
in any other context.
One exception to this is scripts that are deliberately written to
be source compatible with both Python 2.x and 3.x. Such scripts may
continue to use python on their shebang line without affecting their
portability.
To meet this requirement, this commit adds new variables 'PYTHON2'
and 'PYTHON3'.
arch/ia64/scripts/unwcheck.py is the only script that has ever used
$(PYTHON). Recent commit bd5edbe67794 ("ia64: convert unwcheck.py to
python3") converted it to be compatible with both Python 2.x and 3.x,
so this is the exceptional case where the use of 'python' is allowed.
So, I did not touch arch/ia64/Makefile.
tools/perf/Makefile.config sets PYTHON and PYTHON2 by itself, so it
is not affected by this commit.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-03-13 09:12:02 +00:00
|
|
|
PYTHON3 = python3
|
2005-04-16 22:20:36 +00:00
|
|
|
CHECK = sparse
|
2019-08-25 13:28:37 +00:00
|
|
|
BASH = bash
|
kbuild: fix broken builds because of GZIP,BZIP2,LZOP variables
Redefine GZIP, BZIP2, LZOP variables as KGZIP, KBZIP2, KLZOP resp.
GZIP, BZIP2, LZOP env variables are reserved by the tools. The original
attempt to redefine them internally doesn't work in makefiles/scripts
intercall scenarios, e.g., "make GZIP=gzip bindeb-pkg" and results in
broken builds. There can be other broken build commands because of this,
so the universal solution is to use non-reserved env variables for the
compression tools.
Fixes: 8dfb61dcbace ("kbuild: add variables for compression tools")
Signed-off-by: Denis Efremov <efremov@linux.com>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2020-06-08 09:59:44 +00:00
|
|
|
KGZIP = gzip
|
|
|
|
|
KBZIP2 = bzip2
|
|
|
|
|
KLZOP = lzop
|
kbuild: add variables for compression tools
Allow user to use alternative implementations of compression tools,
such as pigz, pbzip2, pxz. For example, multi-threaded tools to
speed up the build:
$ make GZIP=pigz BZIP2=pbzip2
Variables _GZIP, _BZIP2, _LZOP are used internally because original env
vars are reserved by the tools. The use of GZIP in gzip tool is obsolete
since 2015. However, alternative implementations (e.g., pigz) still rely
on it. BZIP2, BZIP, LZOP vars are not obsolescent.
The credit goes to @grsecurity.
As a sidenote, for multi-threaded lzma, xz compression one can use:
$ export XZ_OPT="--threads=0"
Signed-off-by: Denis Efremov <efremov@linux.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2020-06-05 07:39:55 +00:00
|
|
|
LZMA = lzma
|
kbuild: switch from lz4c to lz4 for compression
Replace lz4c with lz4 for kernel image compression.
Although lz4 and lz4c are functionally similar, lz4c has been deprecated
upstream since 2018. Since as early as Ubuntu 16.04 and Fedora 25, lz4
and lz4c have been packaged together, making it safe to update the
requirement from lz4c to lz4.
Consequently, some distributions and build systems, such as OpenEmbedded,
have fully transitioned to using lz4. OpenEmbedded core adopted this
change in commit fe167e082cbd ("bitbake.conf: require lz4 instead of
lz4c"), causing compatibility issues when building the mainline kernel
in the latest OpenEmbedded environment, as seen in the errors below.
This change also updates the LZ4 compression commands to make it backward
compatible by replacing stdin and stdout with the '-' option, due to some
unclear reason, the stdout keyword does not work for lz4 and '-' works for
both. In addition, this modifies the legacy '-c1' with '-9' which is also
compatible with both. This fixes the mainline kernel build failures with
the latest master OpenEmbedded builds associated with the mentioned
compatibility issues.
LZ4 arch/arm/boot/compressed/piggy_data
/bin/sh: 1: lz4c: not found
...
...
ERROR: oe_runmake failed
Link: https://github.com/lz4/lz4/pull/553
Suggested-by: Francesco Dolcini <francesco.dolcini@toradex.com>
Signed-off-by: Parth Pancholi <parth.pancholi@toradex.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-11-14 14:56:44 +00:00
|
|
|
LZ4 = lz4
|
kbuild: add variables for compression tools
Allow user to use alternative implementations of compression tools,
such as pigz, pbzip2, pxz. For example, multi-threaded tools to
speed up the build:
$ make GZIP=pigz BZIP2=pbzip2
Variables _GZIP, _BZIP2, _LZOP are used internally because original env
vars are reserved by the tools. The use of GZIP in gzip tool is obsolete
since 2015. However, alternative implementations (e.g., pigz) still rely
on it. BZIP2, BZIP, LZOP vars are not obsolescent.
The credit goes to @grsecurity.
As a sidenote, for multi-threaded lzma, xz compression one can use:
$ export XZ_OPT="--threads=0"
Signed-off-by: Denis Efremov <efremov@linux.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2020-06-05 07:39:55 +00:00
|
|
|
XZ = xz
|
2020-07-30 19:08:36 +00:00
|
|
|
ZSTD = zstd
|
kbuild: add variables for compression tools
Allow user to use alternative implementations of compression tools,
such as pigz, pbzip2, pxz. For example, multi-threaded tools to
speed up the build:
$ make GZIP=pigz BZIP2=pbzip2
Variables _GZIP, _BZIP2, _LZOP are used internally because original env
vars are reserved by the tools. The use of GZIP in gzip tool is obsolete
since 2015. However, alternative implementations (e.g., pigz) still rely
on it. BZIP2, BZIP, LZOP vars are not obsolescent.
The credit goes to @grsecurity.
As a sidenote, for multi-threaded lzma, xz compression one can use:
$ export XZ_OPT="--threads=0"
Signed-off-by: Denis Efremov <efremov@linux.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2020-06-05 07:39:55 +00:00
|
|
|
|
2008-12-27 21:38:44 +00:00
|
|
|
CHECKFLAGS := -D__linux__ -Dlinux -D__STDC__ -Dunix -D__unix__ \
|
2018-02-15 21:07:50 +00:00
|
|
|
-Wbitwise -Wno-return-void -Wno-unknown-attribute $(CF)
|
2019-03-14 23:41:59 +00:00
|
|
|
NOSTDINC_FLAGS :=
|
kbuild: allow assignment to {A,C,LD}FLAGS_MODULE on the command line
It is now possible to assign options to AS, CC and LD
on the command line - which is only used when building modules.
{A,C,LD}FLAGS_MODULE was all used both in the top-level Makefile
in the arch makefiles, thus users had no way to specify
additional options to AS, CC, LD when building modules
without overriding the original value.
Introduce a new set of variables KBUILD_{A,C,LD}FLAGS_MODULE
that is used by arch specific files and free up
{A,C,LD}FLAGS_MODULE so they can be assigned on
the command line.
All arch Makefiles that used the old variables has been updated.
Note: Previously we had a MODFLAGS variable for both
AS and CC. But in favour of consistency this was dropped.
So in some cases arch Makefile has one assignmnet replaced by
two assignmnets.
Note2: MODFLAGS was not documented and is dropped
without any notice. I do not expect much/any breakage
from this.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Cc: Denys Vlasenko <vda.linux@googlemail.com>
Cc: Haavard Skinnemoen <hskinnemoen@atmel.com>
Cc: Mike Frysinger <vapier@gentoo.org>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Chen Liqin <liqin.chen@sunplusct.com>
Acked-by: Mike Frysinger <vapier@gentoo.org> [blackfin]
Acked-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com> [avr32]
Signed-off-by: Michal Marek <mmarek@suse.cz>
2010-07-28 15:33:09 +00:00
|
|
|
CFLAGS_MODULE =
|
2021-07-03 14:42:57 +00:00
|
|
|
RUSTFLAGS_MODULE =
|
kbuild: allow assignment to {A,C,LD}FLAGS_MODULE on the command line
It is now possible to assign options to AS, CC and LD
on the command line - which is only used when building modules.
{A,C,LD}FLAGS_MODULE was all used both in the top-level Makefile
in the arch makefiles, thus users had no way to specify
additional options to AS, CC, LD when building modules
without overriding the original value.
Introduce a new set of variables KBUILD_{A,C,LD}FLAGS_MODULE
that is used by arch specific files and free up
{A,C,LD}FLAGS_MODULE so they can be assigned on
the command line.
All arch Makefiles that used the old variables has been updated.
Note: Previously we had a MODFLAGS variable for both
AS and CC. But in favour of consistency this was dropped.
So in some cases arch Makefile has one assignmnet replaced by
two assignmnets.
Note2: MODFLAGS was not documented and is dropped
without any notice. I do not expect much/any breakage
from this.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Cc: Denys Vlasenko <vda.linux@googlemail.com>
Cc: Haavard Skinnemoen <hskinnemoen@atmel.com>
Cc: Mike Frysinger <vapier@gentoo.org>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Chen Liqin <liqin.chen@sunplusct.com>
Acked-by: Mike Frysinger <vapier@gentoo.org> [blackfin]
Acked-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com> [avr32]
Signed-off-by: Michal Marek <mmarek@suse.cz>
2010-07-28 15:33:09 +00:00
|
|
|
AFLAGS_MODULE =
|
|
|
|
|
LDFLAGS_MODULE =
|
2005-04-16 22:20:36 +00:00
|
|
|
CFLAGS_KERNEL =
|
2021-07-03 14:42:57 +00:00
|
|
|
RUSTFLAGS_KERNEL =
|
2005-04-16 22:20:36 +00:00
|
|
|
AFLAGS_KERNEL =
|
kbuild: export top-level LDFLAGS_vmlinux only to scripts/Makefile.vmlinux
Nathan Chancellor reports that $(NM) emits an error message when
GNU Make 4.4 is used to build the ARM zImage.
$ make-4.4 ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- O=build defconfig zImage
[snip]
LD vmlinux
NM System.map
SORTTAB vmlinux
OBJCOPY arch/arm/boot/Image
Kernel: arch/arm/boot/Image is ready
arm-linux-gnueabi-nm: 'arch/arm/boot/compressed/../../../../vmlinux': No such file
/bin/sh: 1: arithmetic expression: expecting primary: " "
LDS arch/arm/boot/compressed/vmlinux.lds
AS arch/arm/boot/compressed/head.o
GZIP arch/arm/boot/compressed/piggy_data
AS arch/arm/boot/compressed/piggy.o
CC arch/arm/boot/compressed/misc.o
This occurs since GNU Make commit 98da874c4303 ("[SV 10593] Export
variables to $(shell ...) commands"), and the O= option is needed to
reproduce it. The generated zImage is correct despite the error message.
As the commit description of 98da874c4303 [1] says, exported variables
are passed down to $(shell ) functions, which means exported recursive
variables might be expanded earlier than before, in the parse stage.
The following test code demonstrates the change for GNU Make 4.4.
[Test Makefile]
$(shell echo hello > foo)
export foo = $(shell cat bar/../foo)
$(shell mkdir bar)
all:
@echo $(foo)
[GNU Make 4.3]
$ rm -rf bar; make-4.3
hello
[GNU Make 4.4]
$ rm -rf bar; make-4.4
cat: bar/../foo: No such file or directory
hello
The 'foo' is a resursively expanded (i.e. lazily expanded) variable.
GNU Make 4.3 expands 'foo' just before running the recipe '@echo $(foo)',
at this point, the directory 'bar' exists.
GNU Make 4.4 expands 'foo' to evaluate $(shell mkdir bar) because it is
exported. At this point, the directory 'bar' does not exit yet. The cat
command cannot resolve the bar/../foo path, hence the error message.
Let's get back to the kernel Makefile.
In arch/arm/boot/compressed/Makefile, KBSS_SZ is referenced by
LDFLAGS_vmlinux, which is recursive and also exported by the top
Makefile.
GNU Make 4.3 expands KBSS_SZ just before running the recipes, so no
error message.
GNU Make 4.4 expands KBSS_SZ in the parse stage, where the directory
arm/arm/boot/compressed does not exit yet. When compiled with O=,
the output directory is created by $(shell mkdir -p $(obj-dirs))
in scripts/Makefile.build.
There are two ways to fix this particular issue:
- change "$(obj)/../../../../vmlinux" in KBSS_SZ to "vmlinux"
- unexport LDFLAGS_vmlinux
This commit takes the latter course because it is what I originally
intended.
Commit 3ec8a5b33dea ("kbuild: do not export LDFLAGS_vmlinux")
unexported LDFLAGS_vmlinux.
Commit 5d4aeffbf709 ("kbuild: rebuild .vmlinux.export.o when its
prerequisite is updated") accidentally exported it again.
We can clean up arch/arm/boot/compressed/Makefile later.
[1]: https://git.savannah.gnu.org/cgit/make.git/commit/?id=98da874c43035a490cdca81331724f233a3d0c9a
Link: https://lore.kernel.org/all/Y7i8+EjwdnhHtlrr@dev-arch.thelio-3990X/
Fixes: 5d4aeffbf709 ("kbuild: rebuild .vmlinux.export.o when its prerequisite is updated")
Reported-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
Tested-by: Nathan Chancellor <nathan@kernel.org>
2023-01-08 19:23:17 +00:00
|
|
|
LDFLAGS_vmlinux =
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2012-10-02 17:01:26 +00:00
|
|
|
# Use USERINCLUDE when you must reference the UAPI directories only.
|
|
|
|
|
USERINCLUDE := \
|
2017-10-04 03:56:04 +00:00
|
|
|
-I$(srctree)/arch/$(SRCARCH)/include/uapi \
|
|
|
|
|
-I$(objtree)/arch/$(SRCARCH)/include/generated/uapi \
|
2012-10-02 17:01:26 +00:00
|
|
|
-I$(srctree)/include/uapi \
|
2016-06-15 15:45:45 +00:00
|
|
|
-I$(objtree)/include/generated/uapi \
|
2021-03-04 11:37:08 +00:00
|
|
|
-include $(srctree)/include/linux/compiler-version.h \
|
2012-10-02 17:01:26 +00:00
|
|
|
-include $(srctree)/include/linux/kconfig.h
|
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
# Use LINUXINCLUDE when you must reference the include/ directory.
|
|
|
|
|
# Needed to be compatible with the O= option
|
2012-10-02 17:01:26 +00:00
|
|
|
LINUXINCLUDE := \
|
2017-10-04 03:56:04 +00:00
|
|
|
-I$(srctree)/arch/$(SRCARCH)/include \
|
|
|
|
|
-I$(objtree)/arch/$(SRCARCH)/include/generated \
|
2024-11-10 01:34:33 +00:00
|
|
|
-I$(srctree)/include \
|
2017-06-06 07:15:28 +00:00
|
|
|
-I$(objtree)/include \
|
|
|
|
|
$(USERINCLUDE)
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2018-12-14 08:05:37 +00:00
|
|
|
KBUILD_AFLAGS := -D__ASSEMBLY__ -fno-PIE
|
2023-07-13 18:52:28 +00:00
|
|
|
|
|
|
|
|
KBUILD_CFLAGS :=
|
|
|
|
|
KBUILD_CFLAGS += -std=gnu11
|
|
|
|
|
KBUILD_CFLAGS += -fshort-wchar
|
|
|
|
|
KBUILD_CFLAGS += -funsigned-char
|
|
|
|
|
KBUILD_CFLAGS += -fno-common
|
|
|
|
|
KBUILD_CFLAGS += -fno-PIE
|
|
|
|
|
KBUILD_CFLAGS += -fno-strict-aliasing
|
|
|
|
|
|
kbuild: do not call cc-option before KBUILD_CFLAGS initialization
Some $(call cc-option,...) are invoked very early, even before
KBUILD_CFLAGS, etc. are initialized.
The returned string from $(call cc-option,...) depends on
KBUILD_CPPFLAGS, KBUILD_CFLAGS, and GCC_PLUGINS_CFLAGS.
Since they are exported, they are not empty when the top Makefile
is recursively invoked.
The recursion occurs in several places. For example, the top
Makefile invokes itself for silentoldconfig. "make tinyconfig",
"make rpm-pkg" are the cases, too.
In those cases, the second call of cc-option from the same line
runs a different shell command due to non-pristine KBUILD_CFLAGS.
To get the same result all the time, KBUILD_* and GCC_PLUGINS_CFLAGS
must be initialized before any call of cc-option. This avoids
garbage data in the .cache.mk file.
Move all calls of cc-option below the config targets because target
compiler flags are unnecessary for Kconfig.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
2017-10-12 09:22:25 +00:00
|
|
|
KBUILD_CPPFLAGS := -D__KERNEL__
|
2021-07-03 14:42:57 +00:00
|
|
|
KBUILD_RUSTFLAGS := $(rust_common_flags) \
|
|
|
|
|
-Cpanic=abort -Cembed-bitcode=n -Clto=n \
|
|
|
|
|
-Cforce-unwind-tables=n -Ccodegen-units=1 \
|
|
|
|
|
-Csymbol-mangling-version=v0 \
|
|
|
|
|
-Crelocation-model=static \
|
|
|
|
|
-Zfunction-sections=n \
|
rust: relax most deny-level lints to warnings
Since we are starting to support several Rust toolchains, lints (including
Clippy ones) now may behave differently and lint groups may include
new lints.
Therefore, to maximize the chances a given version works, relax some
deny-level lints to warnings. It may also make our lives a bit easier
while developing new code or refactoring.
To be clear, the requirements for in-tree code are still the same, since
Rust code still needs to be warning-free (patches should be clean under
`WERROR=y`) and the set of lints is not changed.
`unsafe_op_in_unsafe_fn` is left unmodified, i.e. as an error, since it is
becoming the default in the language (warn-by-default in Rust 2024 [1] and
ideally an error later on) and thus it should also be very well tested. In
addition, it is simple enough that it should not have false positives
(unlike e.g. `rust_2018_idioms`'s `explicit_outlives_requirements`).
`non_ascii_idents` is left unmodified as well, i.e. as an error, since
it is unlikely one gains any productivity during development if it
were a warning (in fact, it may be worse, since it is likely one made
a typo). In addition, it should not have false positives.
Finally, put the two `-D` ones at the top and take the chance to do one
per line.
Link: https://github.com/rust-lang/rust/pull/112038 [1]
Reviewed-by: Finn Behrens <me@kloenk.dev>
Tested-by: Benno Lossin <benno.lossin@proton.me>
Tested-by: Andreas Hindborg <a.hindborg@samsung.com>
Link: https://lore.kernel.org/r/20240709160615.998336-5-ojeda@kernel.org
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-07-09 16:05:59 +00:00
|
|
|
-Wclippy::float_arithmetic
|
2021-07-03 14:42:57 +00:00
|
|
|
|
2010-07-28 17:11:27 +00:00
|
|
|
KBUILD_AFLAGS_KERNEL :=
|
|
|
|
|
KBUILD_CFLAGS_KERNEL :=
|
2021-07-03 14:42:57 +00:00
|
|
|
KBUILD_RUSTFLAGS_KERNEL :=
|
kbuild: allow assignment to {A,C,LD}FLAGS_MODULE on the command line
It is now possible to assign options to AS, CC and LD
on the command line - which is only used when building modules.
{A,C,LD}FLAGS_MODULE was all used both in the top-level Makefile
in the arch makefiles, thus users had no way to specify
additional options to AS, CC, LD when building modules
without overriding the original value.
Introduce a new set of variables KBUILD_{A,C,LD}FLAGS_MODULE
that is used by arch specific files and free up
{A,C,LD}FLAGS_MODULE so they can be assigned on
the command line.
All arch Makefiles that used the old variables has been updated.
Note: Previously we had a MODFLAGS variable for both
AS and CC. But in favour of consistency this was dropped.
So in some cases arch Makefile has one assignmnet replaced by
two assignmnets.
Note2: MODFLAGS was not documented and is dropped
without any notice. I do not expect much/any breakage
from this.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Cc: Denys Vlasenko <vda.linux@googlemail.com>
Cc: Haavard Skinnemoen <hskinnemoen@atmel.com>
Cc: Mike Frysinger <vapier@gentoo.org>
Cc: Tony Luck <tony.luck@intel.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Chen Liqin <liqin.chen@sunplusct.com>
Acked-by: Mike Frysinger <vapier@gentoo.org> [blackfin]
Acked-by: Haavard Skinnemoen <haavard.skinnemoen@atmel.com> [avr32]
Signed-off-by: Michal Marek <mmarek@suse.cz>
2010-07-28 15:33:09 +00:00
|
|
|
KBUILD_AFLAGS_MODULE := -DMODULE
|
|
|
|
|
KBUILD_CFLAGS_MODULE := -DMODULE
|
2021-07-03 14:42:57 +00:00
|
|
|
KBUILD_RUSTFLAGS_MODULE := --cfg MODULE
|
2019-08-14 16:06:22 +00:00
|
|
|
KBUILD_LDFLAGS_MODULE :=
|
2018-08-23 23:20:39 +00:00
|
|
|
KBUILD_LDFLAGS :=
|
2019-07-29 09:15:17 +00:00
|
|
|
CLANG_FLAGS :=
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2021-07-03 14:42:57 +00:00
|
|
|
ifeq ($(KBUILD_CLIPPY),1)
|
|
|
|
|
RUSTC_OR_CLIPPY_QUIET := CLIPPY
|
|
|
|
|
RUSTC_OR_CLIPPY = $(CLIPPY_DRIVER)
|
|
|
|
|
else
|
|
|
|
|
RUSTC_OR_CLIPPY_QUIET := RUSTC
|
|
|
|
|
RUSTC_OR_CLIPPY = $(RUSTC)
|
|
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
# Allows the usage of unstable features in stable compilers.
|
|
|
|
|
export RUSTC_BOOTSTRAP := 1
|
|
|
|
|
|
2024-09-04 20:43:39 +00:00
|
|
|
# Allows finding `.clippy.toml` in out-of-srctree builds.
|
|
|
|
|
export CLIPPY_CONF_DIR := $(srctree)
|
|
|
|
|
|
2022-04-01 23:18:02 +00:00
|
|
|
export ARCH SRCARCH CONFIG_SHELL BASH HOSTCC KBUILD_HOSTCFLAGS CROSS_COMPILE LD CC HOSTPKG_CONFIG
|
2024-05-28 16:35:02 +00:00
|
|
|
export RUSTC RUSTDOC RUSTFMT RUSTC_OR_CLIPPY_QUIET RUSTC_OR_CLIPPY BINDGEN
|
2021-07-03 14:42:57 +00:00
|
|
|
export HOSTRUSTC KBUILD_HOSTRUSTFLAGS
|
2020-10-23 11:57:32 +00:00
|
|
|
export CPP AR NM STRIP OBJCOPY OBJDUMP READELF PAHOLE RESOLVE_BTFIDS LEX YACC AWK INSTALLKERNEL
|
2021-02-01 01:00:24 +00:00
|
|
|
export PERL PYTHON3 CHECK CHECKFLAGS MAKE UTS_MACHINE HOSTCXX
|
2020-07-30 19:08:36 +00:00
|
|
|
export KGZIP KBZIP2 KLZOP LZMA LZ4 XZ ZSTD
|
2019-01-21 12:54:39 +00:00
|
|
|
export KBUILD_HOSTCXXFLAGS KBUILD_HOSTLDFLAGS KBUILD_HOSTLDLIBS LDFLAGS_MODULE
|
2022-02-01 21:35:42 +00:00
|
|
|
export KBUILD_USERCFLAGS KBUILD_USERLDFLAGS
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2018-08-23 23:20:39 +00:00
|
|
|
export KBUILD_CPPFLAGS NOSTDINC_FLAGS LINUXINCLUDE OBJCOPYFLAGS KBUILD_LDFLAGS
|
2018-02-06 23:36:00 +00:00
|
|
|
export KBUILD_CFLAGS CFLAGS_KERNEL CFLAGS_MODULE
|
2021-07-03 14:42:57 +00:00
|
|
|
export KBUILD_RUSTFLAGS RUSTFLAGS_KERNEL RUSTFLAGS_MODULE
|
2007-10-15 19:59:31 +00:00
|
|
|
export KBUILD_AFLAGS AFLAGS_KERNEL AFLAGS_MODULE
|
2021-07-03 14:42:57 +00:00
|
|
|
export KBUILD_AFLAGS_MODULE KBUILD_CFLAGS_MODULE KBUILD_RUSTFLAGS_MODULE KBUILD_LDFLAGS_MODULE
|
|
|
|
|
export KBUILD_AFLAGS_KERNEL KBUILD_CFLAGS_KERNEL KBUILD_RUSTFLAGS_KERNEL
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
|
# Files to ignore in find ... statements
|
|
|
|
|
|
2014-02-06 12:51:42 +00:00
|
|
|
export RCS_FIND_IGNORE := \( -name SCCS -o -name BitKeeper -o -name .svn -o \
|
|
|
|
|
-name CVS -o -name .pc -o -name .hg -o -name .git \) \
|
|
|
|
|
-prune -o
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
|
# ===========================================================================
|
|
|
|
|
# Rules shared between *config targets and build targets
|
|
|
|
|
|
2017-08-02 02:31:06 +00:00
|
|
|
# Basic helpers built in scripts/basic/
|
2006-03-05 22:14:10 +00:00
|
|
|
PHONY += scripts_basic
|
2005-04-16 22:20:36 +00:00
|
|
|
scripts_basic:
|
|
|
|
|
$(Q)$(MAKE) $(build)=scripts/basic
|
|
|
|
|
|
2006-03-05 22:14:10 +00:00
|
|
|
PHONY += outputmakefile
|
2021-05-17 07:03:11 +00:00
|
|
|
ifdef building_out_of_srctree
|
2019-08-22 04:46:11 +00:00
|
|
|
# Before starting out-of-tree build, make sure the source tree is clean.
|
2006-05-02 10:33:20 +00:00
|
|
|
# outputmakefile generates a Makefile in the output directory, if using a
|
|
|
|
|
# separate output directory. This allows convenient use of make in the
|
|
|
|
|
# output directory.
|
2019-02-03 08:48:40 +00:00
|
|
|
# At the same time when output Makefile generated, generate .gitignore to
|
|
|
|
|
# ignore whole output directory
|
2021-05-17 07:03:11 +00:00
|
|
|
|
2024-11-10 01:34:38 +00:00
|
|
|
ifdef KBUILD_EXTMOD
|
|
|
|
|
print_env_for_makefile = \
|
|
|
|
|
echo "export KBUILD_OUTPUT = $(objtree)"; \
|
|
|
|
|
echo "export KBUILD_EXTMOD = $(realpath $(srcroot))" ; \
|
|
|
|
|
echo "export KBUILD_EXTMOD_OUTPUT = $(CURDIR)"
|
|
|
|
|
else
|
|
|
|
|
print_env_for_makefile = \
|
|
|
|
|
echo "export KBUILD_OUTPUT = $(CURDIR)"
|
|
|
|
|
endif
|
|
|
|
|
|
2021-05-17 07:03:11 +00:00
|
|
|
quiet_cmd_makefile = GEN Makefile
|
|
|
|
|
cmd_makefile = { \
|
2024-11-10 01:34:37 +00:00
|
|
|
echo "\# Automatically generated by $(abs_srctree)/Makefile: don't edit"; \
|
2024-11-10 01:34:38 +00:00
|
|
|
$(print_env_for_makefile); \
|
2024-11-10 01:34:37 +00:00
|
|
|
echo "include $(abs_srctree)/Makefile"; \
|
2021-05-17 07:03:11 +00:00
|
|
|
} > Makefile
|
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
outputmakefile:
|
2024-11-10 01:34:35 +00:00
|
|
|
ifeq ($(KBUILD_EXTMOD),)
|
2022-09-24 08:24:25 +00:00
|
|
|
@if [ -f $(srctree)/.config -o \
|
2019-08-22 04:46:11 +00:00
|
|
|
-d $(srctree)/include/config -o \
|
|
|
|
|
-d $(srctree)/arch/$(SRCARCH)/include/generated ]; then \
|
|
|
|
|
echo >&2 "***"; \
|
|
|
|
|
echo >&2 "*** The source tree is not clean, please run 'make$(if $(findstring command line, $(origin ARCH)), ARCH=$(ARCH)) mrproper'"; \
|
|
|
|
|
echo >&2 "*** in $(abs_srctree)";\
|
|
|
|
|
echo >&2 "***"; \
|
|
|
|
|
false; \
|
|
|
|
|
fi
|
2024-11-10 01:34:35 +00:00
|
|
|
else
|
|
|
|
|
@if [ -f $(srcroot)/modules.order ]; then \
|
|
|
|
|
echo >&2 "***"; \
|
|
|
|
|
echo >&2 "*** The external module source tree is not clean."; \
|
|
|
|
|
echo >&2 "*** Please run 'make -C $(abs_srctree) M=$(realpath $(srcroot)) clean'"; \
|
|
|
|
|
echo >&2 "***"; \
|
|
|
|
|
false; \
|
|
|
|
|
fi
|
|
|
|
|
endif
|
|
|
|
|
$(Q)ln -fsn $(srcroot) source
|
2021-05-17 07:03:11 +00:00
|
|
|
$(call cmd,makefile)
|
2019-03-26 04:26:58 +00:00
|
|
|
$(Q)test -e .gitignore || \
|
|
|
|
|
{ echo "# this is build directory, ignore it"; echo "*"; } > .gitignore
|
2006-05-02 10:33:20 +00:00
|
|
|
endif
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2021-02-05 22:01:25 +00:00
|
|
|
# The expansion should be delayed until arch/$(SRCARCH)/Makefile is included.
|
|
|
|
|
# Some architectures define CROSS_COMPILE in arch/$(SRCARCH)/Makefile.
|
2024-09-02 16:55:29 +00:00
|
|
|
# CC_VERSION_TEXT and RUSTC_VERSION_TEXT are referenced from Kconfig (so they
|
|
|
|
|
# need export), and from include/config/auto.conf.cmd to detect the compiler
|
|
|
|
|
# upgrade.
|
2021-08-01 02:53:46 +00:00
|
|
|
CC_VERSION_TEXT = $(subst $(pound),,$(shell LC_ALL=C $(CC) --version 2>/dev/null | head -n 1))
|
2024-09-02 16:55:29 +00:00
|
|
|
RUSTC_VERSION_TEXT = $(subst $(pound),,$(shell $(RUSTC) --version 2>/dev/null))
|
2021-02-05 22:01:25 +00:00
|
|
|
|
|
|
|
|
ifneq ($(findstring clang,$(CC_VERSION_TEXT)),)
|
2021-08-02 18:39:08 +00:00
|
|
|
include $(srctree)/scripts/Makefile.clang
|
2017-11-07 19:46:13 +00:00
|
|
|
endif
|
|
|
|
|
|
2021-02-28 06:10:27 +00:00
|
|
|
# Include this also for config targets because some architectures need
|
|
|
|
|
# cc-cross-prefix to determine CROSS_COMPILE.
|
2021-02-28 06:10:28 +00:00
|
|
|
ifdef need-compiler
|
2021-02-28 06:10:27 +00:00
|
|
|
include $(srctree)/scripts/Makefile.compiler
|
2021-02-28 06:10:28 +00:00
|
|
|
endif
|
2021-02-28 06:10:27 +00:00
|
|
|
|
2019-08-10 15:53:03 +00:00
|
|
|
ifdef config-build
|
2005-04-16 22:20:36 +00:00
|
|
|
# ===========================================================================
|
|
|
|
|
# *config targets only - make sure prerequisites are updated, and descend
|
|
|
|
|
# in scripts/kconfig to make the *config target
|
|
|
|
|
|
2023-10-26 07:26:23 +00:00
|
|
|
# Read arch-specific Makefile to set KBUILD_DEFCONFIG as needed.
|
2005-04-16 22:20:36 +00:00
|
|
|
# KBUILD_DEFCONFIG may point out an alternative default configuration
|
|
|
|
|
# used for 'make defconfig'
|
2021-02-28 06:10:26 +00:00
|
|
|
include $(srctree)/arch/$(SRCARCH)/Makefile
|
2024-09-02 16:55:29 +00:00
|
|
|
export KBUILD_DEFCONFIG KBUILD_KCONFIG CC_VERSION_TEXT RUSTC_VERSION_TEXT
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2019-08-22 04:46:13 +00:00
|
|
|
config: outputmakefile scripts_basic FORCE
|
2008-12-13 22:00:45 +00:00
|
|
|
$(Q)$(MAKE) $(build)=scripts/kconfig $@
|
|
|
|
|
|
2019-08-22 04:46:13 +00:00
|
|
|
%config: outputmakefile scripts_basic FORCE
|
2005-04-16 22:20:36 +00:00
|
|
|
$(Q)$(MAKE) $(build)=scripts/kconfig $@
|
|
|
|
|
|
2019-08-10 15:53:03 +00:00
|
|
|
else #!config-build
|
2005-04-16 22:20:36 +00:00
|
|
|
# ===========================================================================
|
2023-10-26 07:26:23 +00:00
|
|
|
# Build targets only - this includes vmlinux, arch-specific targets, clean
|
2005-04-16 22:20:36 +00:00
|
|
|
# targets and others. In general all targets except *config targets.
|
|
|
|
|
|
2017-10-04 03:56:06 +00:00
|
|
|
# If building an external module we do not care about the all: rule
|
2020-05-11 03:50:13 +00:00
|
|
|
# but instead __all depend on modules
|
2017-10-04 03:56:06 +00:00
|
|
|
PHONY += all
|
|
|
|
|
ifeq ($(KBUILD_EXTMOD),)
|
2020-05-11 03:50:13 +00:00
|
|
|
__all: all
|
2017-10-04 03:56:06 +00:00
|
|
|
else
|
2020-05-11 03:50:13 +00:00
|
|
|
__all: modules
|
2017-10-04 03:56:06 +00:00
|
|
|
endif
|
|
|
|
|
|
2022-09-24 18:19:14 +00:00
|
|
|
targets :=
|
|
|
|
|
|
2017-10-04 03:56:06 +00:00
|
|
|
# Decide whether to build built-in, modular, or both.
|
|
|
|
|
# Normally, just do built-in.
|
|
|
|
|
|
|
|
|
|
KBUILD_MODULES :=
|
|
|
|
|
KBUILD_BUILTIN := 1
|
|
|
|
|
|
|
|
|
|
# If we have only "make modules", don't compile built-in objects.
|
|
|
|
|
ifeq ($(MAKECMDGOALS),modules)
|
2020-05-31 08:47:06 +00:00
|
|
|
KBUILD_BUILTIN :=
|
2017-10-04 03:56:06 +00:00
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
# If we have "make <whatever> modules", compile modules
|
|
|
|
|
# in addition to whatever we do anyway.
|
|
|
|
|
# Just "make" or "make all" shall build modules as well
|
|
|
|
|
|
2024-11-10 01:34:33 +00:00
|
|
|
ifneq ($(filter all modules nsdeps compile_commands.json clang-%,$(MAKECMDGOALS)),)
|
2017-10-04 03:56:06 +00:00
|
|
|
KBUILD_MODULES := 1
|
|
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
ifeq ($(MAKECMDGOALS),)
|
|
|
|
|
KBUILD_MODULES := 1
|
|
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
export KBUILD_MODULES KBUILD_BUILTIN
|
|
|
|
|
|
2019-08-10 15:53:03 +00:00
|
|
|
ifdef need-config
|
2024-11-10 01:34:30 +00:00
|
|
|
include $(objtree)/include/config/auto.conf
|
2019-04-27 03:33:36 +00:00
|
|
|
endif
|
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
ifeq ($(KBUILD_EXTMOD),)
|
|
|
|
|
# Objects we will link into vmlinux / subdirs we need to visit
|
2022-09-24 18:19:10 +00:00
|
|
|
core-y :=
|
|
|
|
|
drivers-y :=
|
2005-04-16 22:20:36 +00:00
|
|
|
libs-y := lib/
|
|
|
|
|
endif # KBUILD_EXTMOD
|
|
|
|
|
|
kbuild: fix endless syncconfig in case arch Makefile sets CROSS_COMPILE
Commit 21c54b774744 ("kconfig: show compiler version text in the top
comment") was intended to detect the compiler upgrade, but Geert
reported a breakage on the m68k build.
The compiler upgrade is detected by the change of the environment
variable, CC_VERSION_TEXT, which contains the first line of the output
from $(CC) --version. Currently, this works well when CROSS_COMPILE
is given via the environment variable or the Make command line.
However, some architectures such as m68k can specify CROSS_COMPILE
from arch/$(SRCARCH)/Makefile as well. In this case, "make ARCH=m68k"
ends up with endless syncconfig loop.
$ make ARCH=m68k defconfig
*** Default configuration is based on 'multi_defconfig'
#
# configuration written to .config
#
$ make ARCH=m68k
scripts/kconfig/conf --syncconfig Kconfig
scripts/kconfig/conf --syncconfig Kconfig
scripts/kconfig/conf --syncconfig Kconfig
scripts/kconfig/conf --syncconfig Kconfig
Things are happening like this:
Because arch/$(SRCARCH)/Makefile is included after CC_VERSION_TEXT
is set, it contains the host compiler version in the defconfig phase.
To create or update auto.conf, the following line is triggered:
include/config/%.conf: $(KCONFIG_CONFIG) include/config/auto.conf.cmd
$(Q)$(MAKE) -f $(srctree)/Makefile syncconfig
This recurses the top Makefile after arch/$(SRCARCH)/Makefile is
included. CROSS_COMPILE is set to a m68k toolchain prefix and
exported to the recursed Make. Then, syncconfig is invoked with
the target compiler version in CC_VERSION_TEXT.
The Make will restart because auto.conf and auto.conf.cmd have been
updated. At this point, CROSS_COMPILE is reset, so CC_VERSION_TEXT
is set to the host compiler version again. Then, syncconfig is
triggered due to the change of CC_VERSION_TEXT. This loop continues
eternally.
To fix this problem, $(CC_VERSION_TEXT) must be evaluated only after
arch/$(SRCARCH)/Makefile. Setting it earlier is OK as long as it is
defined by using the '=' operator instead of ':='.
For the defconfig phase, $(CC_VERSION_TEXT) is evaluated when Kbuild
descends into scripts/kconfig/, so it contains the target compiler
version correctly.
include/config/auto.conf.cmd references $(CC_VERSION_TEXT) as well,
so it must be included after arch/$(SRCARCH)/Makefile.
Fixes: 21c54b774744 ("kconfig: show compiler version text in the top comment")
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Tested-by: Geert Uytterhoeven <geert@linux-m68k.org>
2018-06-08 00:21:43 +00:00
|
|
|
# The all: target is the default when no target is given on the
|
|
|
|
|
# command line.
|
|
|
|
|
# This allow a user to issue only 'make' to build a kernel including modules
|
|
|
|
|
# Defaults to vmlinux, but the arch makefile usually adds further targets
|
|
|
|
|
all: vmlinux
|
|
|
|
|
|
Makefile: remove stale cc-option checks
cc-option, cc-option-yn, and cc-disable-warning all invoke the compiler
during build time, and can slow down the build when these checks become
stale for our supported compilers, whose minimally supported versions
increases over time. See Documentation/process/changes.rst for the
current supported minimal versions (GCC 4.9+, clang 10.0.1+). Compiler
version support for these flags may be verified on godbolt.org.
The following flags are GCC only and supported since at least GCC 4.9.
Remove cc-option and cc-disable-warning tests.
* -fno-tree-loop-im
* -Wno-maybe-uninitialized
* -fno-reorder-blocks
* -fno-ipa-cp-clone
* -fno-partial-inlining
* -femit-struct-debug-baseonly
* -fno-inline-functions-called-once
* -fconserve-stack
The following flags are supported by all supported versions of GCC and
Clang. Remove their cc-option, cc-option-yn, and cc-disable-warning tests.
* -fno-delete-null-pointer-checks
* -fno-var-tracking
* -Wno-array-bounds
The following configs are made dependent on GCC, since they use GCC
specific flags.
* READABLE_ASM
* DEBUG_SECTION_MISMATCH
-mfentry was not supported by s390-linux-gnu-gcc until gcc-9+, add a
comment.
--param=allow-store-data-races=0 was renamed to -fno-allow-store-data-races
in the GCC 10 release; add a comment.
-Wmaybe-uninitialized (GCC specific) was being added for CONFIG_GCOV,
then again unconditionally; add it only once.
Also, base RETPOLINE_CFLAGS and RETPOLINE_VDSO_CFLAGS on CONFIC_CC_IS_*
then remove cc-option tests for Clang.
Link: https://github.com/ClangBuiltLinux/linux/issues/1436
Acked-by: Miguel Ojeda <ojeda@kernel.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2021-08-16 20:25:01 +00:00
|
|
|
CFLAGS_GCOV := -fprofile-arcs -ftest-coverage
|
|
|
|
|
ifdef CONFIG_CC_IS_GCC
|
|
|
|
|
CFLAGS_GCOV += -fno-tree-loop-im
|
|
|
|
|
endif
|
2018-05-28 09:22:04 +00:00
|
|
|
export CFLAGS_GCOV
|
kbuild: fix endless syncconfig in case arch Makefile sets CROSS_COMPILE
Commit 21c54b774744 ("kconfig: show compiler version text in the top
comment") was intended to detect the compiler upgrade, but Geert
reported a breakage on the m68k build.
The compiler upgrade is detected by the change of the environment
variable, CC_VERSION_TEXT, which contains the first line of the output
from $(CC) --version. Currently, this works well when CROSS_COMPILE
is given via the environment variable or the Make command line.
However, some architectures such as m68k can specify CROSS_COMPILE
from arch/$(SRCARCH)/Makefile as well. In this case, "make ARCH=m68k"
ends up with endless syncconfig loop.
$ make ARCH=m68k defconfig
*** Default configuration is based on 'multi_defconfig'
#
# configuration written to .config
#
$ make ARCH=m68k
scripts/kconfig/conf --syncconfig Kconfig
scripts/kconfig/conf --syncconfig Kconfig
scripts/kconfig/conf --syncconfig Kconfig
scripts/kconfig/conf --syncconfig Kconfig
Things are happening like this:
Because arch/$(SRCARCH)/Makefile is included after CC_VERSION_TEXT
is set, it contains the host compiler version in the defconfig phase.
To create or update auto.conf, the following line is triggered:
include/config/%.conf: $(KCONFIG_CONFIG) include/config/auto.conf.cmd
$(Q)$(MAKE) -f $(srctree)/Makefile syncconfig
This recurses the top Makefile after arch/$(SRCARCH)/Makefile is
included. CROSS_COMPILE is set to a m68k toolchain prefix and
exported to the recursed Make. Then, syncconfig is invoked with
the target compiler version in CC_VERSION_TEXT.
The Make will restart because auto.conf and auto.conf.cmd have been
updated. At this point, CROSS_COMPILE is reset, so CC_VERSION_TEXT
is set to the host compiler version again. Then, syncconfig is
triggered due to the change of CC_VERSION_TEXT. This loop continues
eternally.
To fix this problem, $(CC_VERSION_TEXT) must be evaluated only after
arch/$(SRCARCH)/Makefile. Setting it earlier is OK as long as it is
defined by using the '=' operator instead of ':='.
For the defconfig phase, $(CC_VERSION_TEXT) is evaluated when Kbuild
descends into scripts/kconfig/, so it contains the target compiler
version correctly.
include/config/auto.conf.cmd references $(CC_VERSION_TEXT) as well,
so it must be included after arch/$(SRCARCH)/Makefile.
Fixes: 21c54b774744 ("kconfig: show compiler version text in the top comment")
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Tested-by: Geert Uytterhoeven <geert@linux-m68k.org>
2018-06-08 00:21:43 +00:00
|
|
|
|
tracing/Makefile: Fix handling redefinition of CC_FLAGS_FTRACE
As a Kernel developer, I make heavy use of "make targz-pkg" in order
to locally compile and remotely install my development Kernels. The
nice feature I rely on is that after a normal "make", "make targz-pkg"
only generates the tarball without having to recompile everything.
That was true until commit f28bc3c32c05 ("tracing: Handle
CC_FLAGS_FTRACE more accurately"). After it, running "make targz-pkg"
after "make" will recompile the whole Kernel tree, making my
development workflow much slower.
The Kernel is choosing to recompile everything because it claims the
command line has changed. A diff of the .cmd files show a repeated
-mfentry in one of the files. That is because "make targz-pkg" calls
"make modules_install" and the environment is already populated with
the exported variables, CC_FLAGS_FTRACE being one of them. Then,
-mfentry gets duplicated because it is not protected behind an ifndef
block, like -pg.
To complicate the problem a little bit more, architectures can define
their own version CC_FLAGS_FTRACE, so our code not only has to
consider recursive Makefiles, but also architecture overrides.
So in this patch we move CC_FLAGS_FTRACE up and unconditionally
define it to -pg. Then we let the architecture Makefiles possibly
override it, and finally append the extra options later. This ensures
the variable is always fully redefined at each invocation so recursive
Makefiles don't keep appending, and hopefully it maintains the
intended behavior on how architectures can override the defaults..
Thanks Steven Rostedt and Vasily Gorbik for the help on this
regression.
Cc: Michal Marek <michal.lkml@markovi.net>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: linux-kbuild@vger.kernel.org
Fixes: commit f28bc3c32c05 ("tracing: Handle CC_FLAGS_FTRACE more accurately")
Acked-by: Vasily Gorbik <gor@linux.ibm.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
2018-09-10 17:59:56 +00:00
|
|
|
# The arch Makefiles can override CC_FLAGS_FTRACE. We may also append it later.
|
|
|
|
|
ifdef CONFIG_FUNCTION_TRACER
|
|
|
|
|
CC_FLAGS_FTRACE := -pg
|
|
|
|
|
endif
|
|
|
|
|
|
2021-02-28 06:10:26 +00:00
|
|
|
include $(srctree)/arch/$(SRCARCH)/Makefile
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2019-08-10 15:53:03 +00:00
|
|
|
ifdef need-config
|
|
|
|
|
ifdef may-sync-config
|
kbuild: fix endless syncconfig in case arch Makefile sets CROSS_COMPILE
Commit 21c54b774744 ("kconfig: show compiler version text in the top
comment") was intended to detect the compiler upgrade, but Geert
reported a breakage on the m68k build.
The compiler upgrade is detected by the change of the environment
variable, CC_VERSION_TEXT, which contains the first line of the output
from $(CC) --version. Currently, this works well when CROSS_COMPILE
is given via the environment variable or the Make command line.
However, some architectures such as m68k can specify CROSS_COMPILE
from arch/$(SRCARCH)/Makefile as well. In this case, "make ARCH=m68k"
ends up with endless syncconfig loop.
$ make ARCH=m68k defconfig
*** Default configuration is based on 'multi_defconfig'
#
# configuration written to .config
#
$ make ARCH=m68k
scripts/kconfig/conf --syncconfig Kconfig
scripts/kconfig/conf --syncconfig Kconfig
scripts/kconfig/conf --syncconfig Kconfig
scripts/kconfig/conf --syncconfig Kconfig
Things are happening like this:
Because arch/$(SRCARCH)/Makefile is included after CC_VERSION_TEXT
is set, it contains the host compiler version in the defconfig phase.
To create or update auto.conf, the following line is triggered:
include/config/%.conf: $(KCONFIG_CONFIG) include/config/auto.conf.cmd
$(Q)$(MAKE) -f $(srctree)/Makefile syncconfig
This recurses the top Makefile after arch/$(SRCARCH)/Makefile is
included. CROSS_COMPILE is set to a m68k toolchain prefix and
exported to the recursed Make. Then, syncconfig is invoked with
the target compiler version in CC_VERSION_TEXT.
The Make will restart because auto.conf and auto.conf.cmd have been
updated. At this point, CROSS_COMPILE is reset, so CC_VERSION_TEXT
is set to the host compiler version again. Then, syncconfig is
triggered due to the change of CC_VERSION_TEXT. This loop continues
eternally.
To fix this problem, $(CC_VERSION_TEXT) must be evaluated only after
arch/$(SRCARCH)/Makefile. Setting it earlier is OK as long as it is
defined by using the '=' operator instead of ':='.
For the defconfig phase, $(CC_VERSION_TEXT) is evaluated when Kbuild
descends into scripts/kconfig/, so it contains the target compiler
version correctly.
include/config/auto.conf.cmd references $(CC_VERSION_TEXT) as well,
so it must be included after arch/$(SRCARCH)/Makefile.
Fixes: 21c54b774744 ("kconfig: show compiler version text in the top comment")
Reported-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Tested-by: Geert Uytterhoeven <geert@linux-m68k.org>
2018-06-08 00:21:43 +00:00
|
|
|
# Read in dependencies to all Kconfig* files, make sure to run syncconfig if
|
|
|
|
|
# changes are detected. This should be included after arch/$(SRCARCH)/Makefile
|
|
|
|
|
# because some architectures define CROSS_COMPILE there.
|
kbuild: turn auto.conf.cmd into a mandatory include file
syncconfig is responsible for keeping auto.conf up-to-date, so if it
fails for any reason, the build must be terminated immediately.
However, since commit 9390dff66a52 ("kbuild: invoke syncconfig if
include/config/auto.conf.cmd is missing"), Kbuild continues running
even after syncconfig fails.
You can confirm this by intentionally making syncconfig error out:
diff --git a/scripts/kconfig/confdata.c b/scripts/kconfig/confdata.c
index 08ba146..307b9de 100644
--- a/scripts/kconfig/confdata.c
+++ b/scripts/kconfig/confdata.c
@@ -1023,6 +1023,9 @@ int conf_write_autoconf(int overwrite)
FILE *out, *tristate, *out_h;
int i;
+ if (overwrite)
+ return 1;
+
if (!overwrite && is_present(autoconf_name))
return 0;
Then, syncconfig fails, but Make would not stop:
$ make -s mrproper allyesconfig defconfig
$ make
scripts/kconfig/conf --syncconfig Kconfig
*** Error during sync of the configuration.
make[2]: *** [scripts/kconfig/Makefile;69: syncconfig] Error 1
make[1]: *** [Makefile;557: syncconfig] Error 2
make: *** [include/config/auto.conf.cmd] Deleting file 'include/config/tristate.conf'
make: Failed to remake makefile 'include/config/auto.conf'.
SYSTBL arch/x86/include/generated/asm/syscalls_32.h
SYSHDR arch/x86/include/generated/asm/unistd_32_ia32.h
SYSHDR arch/x86/include/generated/asm/unistd_64_x32.h
SYSTBL arch/x86/include/generated/asm/syscalls_64.h
[ continue running ... ]
The reason is in the behavior of a pattern rule with multi-targets.
%/auto.conf %/auto.conf.cmd %/tristate.conf: $(KCONFIG_CONFIG)
$(Q)$(MAKE) -f $(srctree)/Makefile syncconfig
GNU Make knows this rule is responsible for making all the three files
simultaneously. As far as examined, auto.conf.cmd is the target in
question when this rule is invoked. It is probably because auto.conf.cmd
is included below the inclusion of auto.conf.
The inclusion of auto.conf is mandatory, while that of auto.conf.cmd
is optional. GNU Make does not care about the failure in the process
of updating optional include files.
I filed this issue (https://savannah.gnu.org/bugs/?56301) in case this
behavior could be improved somehow in future releases of GNU Make.
Anyway, it is quite easy to fix our Makefile.
Given that auto.conf is already a mandatory include file, there is no
reason to stick auto.conf.cmd optional. Make it mandatory as well.
Cc: linux-stable <stable@vger.kernel.org> # 5.0+
Fixes: 9390dff66a52 ("kbuild: invoke syncconfig if include/config/auto.conf.cmd is missing")
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-05-12 02:13:48 +00:00
|
|
|
include include/config/auto.conf.cmd
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2019-02-22 07:40:11 +00:00
|
|
|
$(KCONFIG_CONFIG):
|
|
|
|
|
@echo >&2 '***'
|
|
|
|
|
@echo >&2 '*** Configuration file "$@" not found!'
|
|
|
|
|
@echo >&2 '***'
|
|
|
|
|
@echo >&2 '*** Please run some configurator (e.g. "make oldconfig" or'
|
|
|
|
|
@echo >&2 '*** "make menuconfig" or "make xconfig").'
|
|
|
|
|
@echo >&2 '***'
|
|
|
|
|
@/bin/false
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2018-02-13 07:58:20 +00:00
|
|
|
# The actual configuration files used during the build are stored in
|
|
|
|
|
# include/generated/ and include/config/. Update them if .config is newer than
|
|
|
|
|
# include/config/auto.conf (which mirrors .config).
|
2019-02-22 07:40:10 +00:00
|
|
|
#
|
|
|
|
|
# This exploits the 'multi-target pattern rule' trick.
|
|
|
|
|
# The syncconfig should be executed only once to make all the targets.
|
2020-03-25 03:16:30 +00:00
|
|
|
# (Note: use the grouped target '&:' when we bump to GNU Make 4.3)
|
2021-07-14 04:23:49 +00:00
|
|
|
#
|
|
|
|
|
# Do not use $(call cmd,...) here. That would suppress prompts from syncconfig,
|
|
|
|
|
# so you cannot notice that Kconfig is waiting for the user input.
|
2021-07-03 14:42:57 +00:00
|
|
|
%/config/auto.conf %/config/auto.conf.cmd %/generated/autoconf.h %/generated/rustc_cfg: $(KCONFIG_CONFIG)
|
2021-07-14 04:23:49 +00:00
|
|
|
$(Q)$(kecho) " SYNC $@"
|
|
|
|
|
$(Q)$(MAKE) -f $(srctree)/Makefile syncconfig
|
2019-08-10 15:53:03 +00:00
|
|
|
else # !may-sync-config
|
kbuild: do not update config when running install targets
"make syncconfig" is automatically invoked when any of the following
happens:
- .config is updated
- any of Kconfig files is updated
- any of environment variables referenced in Kconfig is changed
Then, it updates configuration files such as include/config/auto.conf
include/generated/autoconf.h, etc.
Even install targets (install, modules_install, etc.) are no exception.
However, they should never ever modify the source tree. Install
targets are often run with root privileges. Once those configuration
files are owned by root, "make mrproper" would end up with permission
error.
Install targets should just copy things blindly. They should not care
whether the configuration is up-to-date or not. This makes more sense
because we are interested in the configuration that was used in the
previous kernel building.
This issue has existed since before, but rarely happened. I expect
more chance where people are hit by this; with the new Kconfig syntax
extension, the .config now contains the compiler information. If you
cross-compile the kernel with CROSS_COMPILE, but forget to pass it
for "make install", you meet "any of environment variables referenced
in Kconfig is changed" because $(CC) is referenced in Kconfig.
Another scenario is the compiler upgrade before the installation.
Install targets need the configuration. "make modules_install" refer
to CONFIG_MODULES etc. "make dtbs_install" also needs CONFIG_ARCH_*
to decide which dtb files to install. However, the auto-update of
the configuration files should be avoided. We already do this for
external modules.
Now, Make targets are categorized into 3 groups:
[1] Do not need the kernel configuration at all
help, coccicheck, headers_install etc.
[2] Need the latest kernel configuration
If new config options are added, Kconfig will show prompt to
ask user's selection.
Build targets such as vmlinux, in-kernel modules are the cases.
[3] Need the kernel configuration, but do not want to update it
Install targets except headers_install, and external modules
are the cases.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-07-20 07:46:34 +00:00
|
|
|
# External modules and some install targets need include/generated/autoconf.h
|
|
|
|
|
# and include/config/auto.conf but do not care if they are up-to-date.
|
2024-09-17 14:16:38 +00:00
|
|
|
# Use auto.conf to show the error message
|
|
|
|
|
|
2024-11-10 01:34:30 +00:00
|
|
|
checked-configs := $(addprefix $(objtree)/, include/generated/autoconf.h include/generated/rustc_cfg include/config/auto.conf)
|
2024-09-17 14:16:38 +00:00
|
|
|
missing-configs := $(filter-out $(wildcard $(checked-configs)), $(checked-configs))
|
|
|
|
|
|
|
|
|
|
ifdef missing-configs
|
2024-11-10 01:34:30 +00:00
|
|
|
PHONY += $(objtree)/include/config/auto.conf
|
2006-08-07 19:01:36 +00:00
|
|
|
|
2024-11-10 01:34:30 +00:00
|
|
|
$(objtree)/include/config/auto.conf:
|
2024-09-17 14:16:38 +00:00
|
|
|
@echo >&2 '***'
|
|
|
|
|
@echo >&2 '*** ERROR: Kernel configuration is invalid. The following files are missing:'
|
|
|
|
|
@printf >&2 '*** - %s\n' $(missing-configs)
|
|
|
|
|
@echo >&2 '*** Run "make oldconfig && make prepare" on kernel source to fix it.'
|
|
|
|
|
@echo >&2 '***'
|
|
|
|
|
@/bin/false
|
|
|
|
|
endif
|
2006-08-07 19:01:36 +00:00
|
|
|
|
kbuild: do not update config when running install targets
"make syncconfig" is automatically invoked when any of the following
happens:
- .config is updated
- any of Kconfig files is updated
- any of environment variables referenced in Kconfig is changed
Then, it updates configuration files such as include/config/auto.conf
include/generated/autoconf.h, etc.
Even install targets (install, modules_install, etc.) are no exception.
However, they should never ever modify the source tree. Install
targets are often run with root privileges. Once those configuration
files are owned by root, "make mrproper" would end up with permission
error.
Install targets should just copy things blindly. They should not care
whether the configuration is up-to-date or not. This makes more sense
because we are interested in the configuration that was used in the
previous kernel building.
This issue has existed since before, but rarely happened. I expect
more chance where people are hit by this; with the new Kconfig syntax
extension, the .config now contains the compiler information. If you
cross-compile the kernel with CROSS_COMPILE, but forget to pass it
for "make install", you meet "any of environment variables referenced
in Kconfig is changed" because $(CC) is referenced in Kconfig.
Another scenario is the compiler upgrade before the installation.
Install targets need the configuration. "make modules_install" refer
to CONFIG_MODULES etc. "make dtbs_install" also needs CONFIG_ARCH_*
to decide which dtb files to install. However, the auto-update of
the configuration files should be avoided. We already do this for
external modules.
Now, Make targets are categorized into 3 groups:
[1] Do not need the kernel configuration at all
help, coccicheck, headers_install etc.
[2] Need the latest kernel configuration
If new config options are added, Kconfig will show prompt to
ask user's selection.
Build targets such as vmlinux, in-kernel modules are the cases.
[3] Need the kernel configuration, but do not want to update it
Install targets except headers_install, and external modules
are the cases.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-07-20 07:46:34 +00:00
|
|
|
endif # may-sync-config
|
2019-08-10 15:53:03 +00:00
|
|
|
endif # need-config
|
2005-04-16 22:20:36 +00:00
|
|
|
|
Makefile: remove stale cc-option checks
cc-option, cc-option-yn, and cc-disable-warning all invoke the compiler
during build time, and can slow down the build when these checks become
stale for our supported compilers, whose minimally supported versions
increases over time. See Documentation/process/changes.rst for the
current supported minimal versions (GCC 4.9+, clang 10.0.1+). Compiler
version support for these flags may be verified on godbolt.org.
The following flags are GCC only and supported since at least GCC 4.9.
Remove cc-option and cc-disable-warning tests.
* -fno-tree-loop-im
* -Wno-maybe-uninitialized
* -fno-reorder-blocks
* -fno-ipa-cp-clone
* -fno-partial-inlining
* -femit-struct-debug-baseonly
* -fno-inline-functions-called-once
* -fconserve-stack
The following flags are supported by all supported versions of GCC and
Clang. Remove their cc-option, cc-option-yn, and cc-disable-warning tests.
* -fno-delete-null-pointer-checks
* -fno-var-tracking
* -Wno-array-bounds
The following configs are made dependent on GCC, since they use GCC
specific flags.
* READABLE_ASM
* DEBUG_SECTION_MISMATCH
-mfentry was not supported by s390-linux-gnu-gcc until gcc-9+, add a
comment.
--param=allow-store-data-races=0 was renamed to -fno-allow-store-data-races
in the GCC 10 release; add a comment.
-Wmaybe-uninitialized (GCC specific) was being added for CONFIG_GCOV,
then again unconditionally; add it only once.
Also, base RETPOLINE_CFLAGS and RETPOLINE_VDSO_CFLAGS on CONFIC_CC_IS_*
then remove cc-option tests for Clang.
Link: https://github.com/ClangBuiltLinux/linux/issues/1436
Acked-by: Miguel Ojeda <ojeda@kernel.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2021-08-16 20:25:01 +00:00
|
|
|
KBUILD_CFLAGS += -fno-delete-null-pointer-checks
|
Makefile: Fix unrecognized cross-compiler command line options
On architectures that setup CROSS_COMPILE in their arch/*/Makefile
(arc, blackfin, m68k, mips, parisc, score, sh, tile, unicore32, xtensa),
cc-option and cc-disable-warning may check against the wrong compiler,
causing errors like
cc1: error: unrecognized command line option "-Wno-maybe-uninitialized"
if the host gcc supports a compiler option, while the cross compiler
doesn't support that option.
Move all logic using cc-option or cc-disable-warning below the inclusion
of the arch's Makefile to fix this.
Introduced by
- commit e74fc973b6e531fef1fce8b101ffff05ecfb774c ("Turn off
-Wmaybe-uninitialized when building with -Os"),
- commit 61163efae02040f66a95c8ed17f4407951ba58fa ("kbuild: LLVMLinux:
Add Kbuild support for building kernel with Clang").
As -Wno-maybe-uninitialized requires a quite recent gcc (gcc 4.6.3 on
Ubuntu 12.04 LTS doesn't support it), this only showed up recently (gcc
4.8.2 on Ubuntu 14.04 LTS does support it).
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Michal Marek <mmarek@suse.cz>
2014-05-27 07:54:12 +00:00
|
|
|
|
2019-08-20 17:09:40 +00:00
|
|
|
ifdef CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE
|
|
|
|
|
KBUILD_CFLAGS += -O2
|
2021-07-03 14:42:57 +00:00
|
|
|
KBUILD_RUSTFLAGS += -Copt-level=2
|
2019-08-20 17:09:40 +00:00
|
|
|
else ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE
|
|
|
|
|
KBUILD_CFLAGS += -Os
|
2021-07-03 14:42:57 +00:00
|
|
|
KBUILD_RUSTFLAGS += -Copt-level=s
|
2016-04-25 15:35:28 +00:00
|
|
|
endif
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2021-07-03 14:42:57 +00:00
|
|
|
# Always set `debug-assertions` and `overflow-checks` because their default
|
|
|
|
|
# depends on `opt-level` and `debug-assertions`, respectively.
|
|
|
|
|
KBUILD_RUSTFLAGS += -Cdebug-assertions=$(if $(CONFIG_RUST_DEBUG_ASSERTIONS),y,n)
|
|
|
|
|
KBUILD_RUSTFLAGS += -Coverflow-checks=$(if $(CONFIG_RUST_OVERFLOW_CHECKS),y,n)
|
|
|
|
|
|
./Makefile: tell gcc optimizer to never introduce new data races
We have been chasing a memory corruption bug, which turned out to be
caused by very old gcc (4.3.4), which happily turned conditional load
into a non-conditional one, and that broke correctness (the condition
was met only if lock was held) and corrupted memory.
This particular problem with that particular code did not happen when
never gccs were used. I've brought this up with our gcc folks, as I
wanted to make sure that this can't really happen again, and it turns
out it actually can.
Quoting Martin Jambor <mjambor@suse.cz>:
"More current GCCs are more careful when it comes to replacing a
conditional load with a non-conditional one, most notably they check
that a store happens in each iteration of _a_ loop but they assume
loops are executed. They also perform a simple check whether the
store cannot trap which currently passes only for non-const
variables. A simple testcase demonstrating it on an x86_64 is for
example the following:
$ cat cond_store.c
int g_1 = 1;
int g_2[1024] __attribute__((section ("safe_section"), aligned (4096)));
int c = 4;
int __attribute__ ((noinline))
foo (void)
{
int l;
for (l = 0; (l != 4); l++) {
if (g_1)
return l;
for (g_2[0] = 0; (g_2[0] >= 26); ++g_2[0])
;
}
return 2;
}
int main (int argc, char* argv[])
{
if (mprotect (g_2, sizeof(g_2), PROT_READ) == -1)
{
int e = errno;
error (e, e, "mprotect error %i", e);
}
foo ();
__builtin_printf("OK\n");
return 0;
}
/* EOF */
$ ~/gcc/trunk/inst/bin/gcc cond_store.c -O2 --param allow-store-data-races=0
$ ./a.out
OK
$ ~/gcc/trunk/inst/bin/gcc cond_store.c -O2 --param allow-store-data-races=1
$ ./a.out
Segmentation fault
The testcase fails the same at least with 4.9, 4.8 and 4.7. Therefore
I would suggest building kernels with this parameter set to zero. I
also agree with Jikos that the default should be changed for -O2. I
have run most of the SPEC 2k6 CPU benchmarks (gamess and dealII
failed, at -O2, not sure why) compiled with and without this option
and did not see any real difference between respective run-times"
Hopefully the default will be changed in newer gccs, but let's force it
for kernel builds so that we are on a safe side even when older gcc are
used.
The code in question was out-of-tree printk-in-NMI (yeah, surprise
suprise, once again) patch written by Petr Mladek, let me quote his
comment from our internal bugzilla:
"I have spent few days investigating inconsistent state of kernel ring buffer.
It went out that it was caused by speculative store generated by
gcc-4.3.4.
The problem is in assembly generated for make_free_space(). The functions is
called the following way:
+ vprintk_emit();
+ log = MAIN_LOG; // with logbuf_lock
or
log = NMI_LOG; // with nmi_logbuf_lock
cont_add(log, ...);
+ cont_flush(log, ...);
+ log_store(log, ...);
+ log_make_free_space(log, ...);
If called with log = NMI_LOG then only nmi_log_* global variables are safe to
modify but the generated code does store also into (main_)log_* global
variables:
<log_make_free_space>:
55 push %rbp
89 f6 mov %esi,%esi
48 8b 05 03 99 51 01 mov 0x1519903(%rip),%rax # ffffffff82620868 <nmi_log_next_id>
44 8b 1d ec 98 51 01 mov 0x15198ec(%rip),%r11d # ffffffff82620858 <log_next_idx>
8b 35 36 60 14 01 mov 0x1146036(%rip),%esi # ffffffff8224cfa8 <log_buf_len>
44 8b 35 33 60 14 01 mov 0x1146033(%rip),%r14d # ffffffff8224cfac <nmi_log_buf_len>
4c 8b 2d d0 98 51 01 mov 0x15198d0(%rip),%r13 # ffffffff82620850 <log_next_seq>
4c 8b 25 11 61 14 01 mov 0x1146111(%rip),%r12 # ffffffff8224d098 <log_buf>
49 89 c2 mov %rax,%r10
48 21 c2 and %rax,%rdx
48 8b 1d 0c 99 55 01 mov 0x155990c(%rip),%rbx # ffffffff826608a0 <nmi_log_buf>
49 c1 ea 20 shr $0x20,%r10
48 89 55 d0 mov %rdx,-0x30(%rbp)
44 29 de sub %r11d,%esi
45 29 d6 sub %r10d,%r14d
4c 8b 0d 97 98 51 01 mov 0x1519897(%rip),%r9 # ffffffff82620840 <log_first_seq>
eb 7e jmp ffffffff81107029 <log_make_free_space+0xe9>
[...]
85 ff test %edi,%edi # edi = 1 for NMI_LOG
4c 89 e8 mov %r13,%rax
4c 89 ca mov %r9,%rdx
74 0a je ffffffff8110703d <log_make_free_space+0xfd>
8b 15 27 98 51 01 mov 0x1519827(%rip),%edx # ffffffff82620860 <nmi_log_first_id>
48 8b 45 d0 mov -0x30(%rbp),%rax
48 39 c2 cmp %rax,%rdx # end of loop
0f 84 da 00 00 00 je ffffffff81107120 <log_make_free_space+0x1e0>
[...]
85 ff test %edi,%edi # edi = 1 for NMI_LOG
4c 89 0d 17 97 51 01 mov %r9,0x1519717(%rip) # ffffffff82620840 <log_first_seq>
^^^^^^^^^^^^^^^^^^^^^^^^^^
KABOOOM
74 35 je ffffffff81107160 <log_make_free_space+0x220>
It stores log_first_seq when edi == NMI_LOG. This instructions are used also
when edi == MAIN_LOG but the store is done speculatively before the condition
is decided. It is unsafe because we do not have "logbuf_lock" in NMI context
and some other process migh modify "log_first_seq" in parallel"
I believe that the best course of action is both
- building kernel (and anything multi-threaded, I guess) with that
optimization turned off
- persuade gcc folks to change the default for future releases
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Cc: Martin Jambor <mjambor@suse.cz>
Cc: Petr Mladek <pmladek@suse.cz>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Marek Polacek <polacek@redhat.com>
Cc: Jakub Jelinek <jakub@redhat.com>
Cc: Steven Noonan <steven@uplinklabs.net>
Cc: Richard Biener <richard.guenther@gmail.com>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-08-06 23:08:43 +00:00
|
|
|
# Tell gcc to never replace conditional load with a non-conditional one
|
Makefile: remove stale cc-option checks
cc-option, cc-option-yn, and cc-disable-warning all invoke the compiler
during build time, and can slow down the build when these checks become
stale for our supported compilers, whose minimally supported versions
increases over time. See Documentation/process/changes.rst for the
current supported minimal versions (GCC 4.9+, clang 10.0.1+). Compiler
version support for these flags may be verified on godbolt.org.
The following flags are GCC only and supported since at least GCC 4.9.
Remove cc-option and cc-disable-warning tests.
* -fno-tree-loop-im
* -Wno-maybe-uninitialized
* -fno-reorder-blocks
* -fno-ipa-cp-clone
* -fno-partial-inlining
* -femit-struct-debug-baseonly
* -fno-inline-functions-called-once
* -fconserve-stack
The following flags are supported by all supported versions of GCC and
Clang. Remove their cc-option, cc-option-yn, and cc-disable-warning tests.
* -fno-delete-null-pointer-checks
* -fno-var-tracking
* -Wno-array-bounds
The following configs are made dependent on GCC, since they use GCC
specific flags.
* READABLE_ASM
* DEBUG_SECTION_MISMATCH
-mfentry was not supported by s390-linux-gnu-gcc until gcc-9+, add a
comment.
--param=allow-store-data-races=0 was renamed to -fno-allow-store-data-races
in the GCC 10 release; add a comment.
-Wmaybe-uninitialized (GCC specific) was being added for CONFIG_GCOV,
then again unconditionally; add it only once.
Also, base RETPOLINE_CFLAGS and RETPOLINE_VDSO_CFLAGS on CONFIC_CC_IS_*
then remove cc-option tests for Clang.
Link: https://github.com/ClangBuiltLinux/linux/issues/1436
Acked-by: Miguel Ojeda <ojeda@kernel.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2021-08-16 20:25:01 +00:00
|
|
|
ifdef CONFIG_CC_IS_GCC
|
|
|
|
|
# gcc-10 renamed --param=allow-store-data-races=0 to
|
|
|
|
|
# -fno-allow-store-data-races.
|
./Makefile: tell gcc optimizer to never introduce new data races
We have been chasing a memory corruption bug, which turned out to be
caused by very old gcc (4.3.4), which happily turned conditional load
into a non-conditional one, and that broke correctness (the condition
was met only if lock was held) and corrupted memory.
This particular problem with that particular code did not happen when
never gccs were used. I've brought this up with our gcc folks, as I
wanted to make sure that this can't really happen again, and it turns
out it actually can.
Quoting Martin Jambor <mjambor@suse.cz>:
"More current GCCs are more careful when it comes to replacing a
conditional load with a non-conditional one, most notably they check
that a store happens in each iteration of _a_ loop but they assume
loops are executed. They also perform a simple check whether the
store cannot trap which currently passes only for non-const
variables. A simple testcase demonstrating it on an x86_64 is for
example the following:
$ cat cond_store.c
int g_1 = 1;
int g_2[1024] __attribute__((section ("safe_section"), aligned (4096)));
int c = 4;
int __attribute__ ((noinline))
foo (void)
{
int l;
for (l = 0; (l != 4); l++) {
if (g_1)
return l;
for (g_2[0] = 0; (g_2[0] >= 26); ++g_2[0])
;
}
return 2;
}
int main (int argc, char* argv[])
{
if (mprotect (g_2, sizeof(g_2), PROT_READ) == -1)
{
int e = errno;
error (e, e, "mprotect error %i", e);
}
foo ();
__builtin_printf("OK\n");
return 0;
}
/* EOF */
$ ~/gcc/trunk/inst/bin/gcc cond_store.c -O2 --param allow-store-data-races=0
$ ./a.out
OK
$ ~/gcc/trunk/inst/bin/gcc cond_store.c -O2 --param allow-store-data-races=1
$ ./a.out
Segmentation fault
The testcase fails the same at least with 4.9, 4.8 and 4.7. Therefore
I would suggest building kernels with this parameter set to zero. I
also agree with Jikos that the default should be changed for -O2. I
have run most of the SPEC 2k6 CPU benchmarks (gamess and dealII
failed, at -O2, not sure why) compiled with and without this option
and did not see any real difference between respective run-times"
Hopefully the default will be changed in newer gccs, but let's force it
for kernel builds so that we are on a safe side even when older gcc are
used.
The code in question was out-of-tree printk-in-NMI (yeah, surprise
suprise, once again) patch written by Petr Mladek, let me quote his
comment from our internal bugzilla:
"I have spent few days investigating inconsistent state of kernel ring buffer.
It went out that it was caused by speculative store generated by
gcc-4.3.4.
The problem is in assembly generated for make_free_space(). The functions is
called the following way:
+ vprintk_emit();
+ log = MAIN_LOG; // with logbuf_lock
or
log = NMI_LOG; // with nmi_logbuf_lock
cont_add(log, ...);
+ cont_flush(log, ...);
+ log_store(log, ...);
+ log_make_free_space(log, ...);
If called with log = NMI_LOG then only nmi_log_* global variables are safe to
modify but the generated code does store also into (main_)log_* global
variables:
<log_make_free_space>:
55 push %rbp
89 f6 mov %esi,%esi
48 8b 05 03 99 51 01 mov 0x1519903(%rip),%rax # ffffffff82620868 <nmi_log_next_id>
44 8b 1d ec 98 51 01 mov 0x15198ec(%rip),%r11d # ffffffff82620858 <log_next_idx>
8b 35 36 60 14 01 mov 0x1146036(%rip),%esi # ffffffff8224cfa8 <log_buf_len>
44 8b 35 33 60 14 01 mov 0x1146033(%rip),%r14d # ffffffff8224cfac <nmi_log_buf_len>
4c 8b 2d d0 98 51 01 mov 0x15198d0(%rip),%r13 # ffffffff82620850 <log_next_seq>
4c 8b 25 11 61 14 01 mov 0x1146111(%rip),%r12 # ffffffff8224d098 <log_buf>
49 89 c2 mov %rax,%r10
48 21 c2 and %rax,%rdx
48 8b 1d 0c 99 55 01 mov 0x155990c(%rip),%rbx # ffffffff826608a0 <nmi_log_buf>
49 c1 ea 20 shr $0x20,%r10
48 89 55 d0 mov %rdx,-0x30(%rbp)
44 29 de sub %r11d,%esi
45 29 d6 sub %r10d,%r14d
4c 8b 0d 97 98 51 01 mov 0x1519897(%rip),%r9 # ffffffff82620840 <log_first_seq>
eb 7e jmp ffffffff81107029 <log_make_free_space+0xe9>
[...]
85 ff test %edi,%edi # edi = 1 for NMI_LOG
4c 89 e8 mov %r13,%rax
4c 89 ca mov %r9,%rdx
74 0a je ffffffff8110703d <log_make_free_space+0xfd>
8b 15 27 98 51 01 mov 0x1519827(%rip),%edx # ffffffff82620860 <nmi_log_first_id>
48 8b 45 d0 mov -0x30(%rbp),%rax
48 39 c2 cmp %rax,%rdx # end of loop
0f 84 da 00 00 00 je ffffffff81107120 <log_make_free_space+0x1e0>
[...]
85 ff test %edi,%edi # edi = 1 for NMI_LOG
4c 89 0d 17 97 51 01 mov %r9,0x1519717(%rip) # ffffffff82620840 <log_first_seq>
^^^^^^^^^^^^^^^^^^^^^^^^^^
KABOOOM
74 35 je ffffffff81107160 <log_make_free_space+0x220>
It stores log_first_seq when edi == NMI_LOG. This instructions are used also
when edi == MAIN_LOG but the store is done speculatively before the condition
is decided. It is unsafe because we do not have "logbuf_lock" in NMI context
and some other process migh modify "log_first_seq" in parallel"
I believe that the best course of action is both
- building kernel (and anything multi-threaded, I guess) with that
optimization turned off
- persuade gcc folks to change the default for future releases
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Cc: Martin Jambor <mjambor@suse.cz>
Cc: Petr Mladek <pmladek@suse.cz>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Marek Polacek <polacek@redhat.com>
Cc: Jakub Jelinek <jakub@redhat.com>
Cc: Steven Noonan <steven@uplinklabs.net>
Cc: Richard Biener <richard.guenther@gmail.com>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-08-06 23:08:43 +00:00
|
|
|
KBUILD_CFLAGS += $(call cc-option,--param=allow-store-data-races=0)
|
2020-03-17 00:07:18 +00:00
|
|
|
KBUILD_CFLAGS += $(call cc-option,-fno-allow-store-data-races)
|
Makefile: remove stale cc-option checks
cc-option, cc-option-yn, and cc-disable-warning all invoke the compiler
during build time, and can slow down the build when these checks become
stale for our supported compilers, whose minimally supported versions
increases over time. See Documentation/process/changes.rst for the
current supported minimal versions (GCC 4.9+, clang 10.0.1+). Compiler
version support for these flags may be verified on godbolt.org.
The following flags are GCC only and supported since at least GCC 4.9.
Remove cc-option and cc-disable-warning tests.
* -fno-tree-loop-im
* -Wno-maybe-uninitialized
* -fno-reorder-blocks
* -fno-ipa-cp-clone
* -fno-partial-inlining
* -femit-struct-debug-baseonly
* -fno-inline-functions-called-once
* -fconserve-stack
The following flags are supported by all supported versions of GCC and
Clang. Remove their cc-option, cc-option-yn, and cc-disable-warning tests.
* -fno-delete-null-pointer-checks
* -fno-var-tracking
* -Wno-array-bounds
The following configs are made dependent on GCC, since they use GCC
specific flags.
* READABLE_ASM
* DEBUG_SECTION_MISMATCH
-mfentry was not supported by s390-linux-gnu-gcc until gcc-9+, add a
comment.
--param=allow-store-data-races=0 was renamed to -fno-allow-store-data-races
in the GCC 10 release; add a comment.
-Wmaybe-uninitialized (GCC specific) was being added for CONFIG_GCOV,
then again unconditionally; add it only once.
Also, base RETPOLINE_CFLAGS and RETPOLINE_VDSO_CFLAGS on CONFIC_CC_IS_*
then remove cc-option tests for Clang.
Link: https://github.com/ClangBuiltLinux/linux/issues/1436
Acked-by: Miguel Ojeda <ojeda@kernel.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2021-08-16 20:25:01 +00:00
|
|
|
endif
|
./Makefile: tell gcc optimizer to never introduce new data races
We have been chasing a memory corruption bug, which turned out to be
caused by very old gcc (4.3.4), which happily turned conditional load
into a non-conditional one, and that broke correctness (the condition
was met only if lock was held) and corrupted memory.
This particular problem with that particular code did not happen when
never gccs were used. I've brought this up with our gcc folks, as I
wanted to make sure that this can't really happen again, and it turns
out it actually can.
Quoting Martin Jambor <mjambor@suse.cz>:
"More current GCCs are more careful when it comes to replacing a
conditional load with a non-conditional one, most notably they check
that a store happens in each iteration of _a_ loop but they assume
loops are executed. They also perform a simple check whether the
store cannot trap which currently passes only for non-const
variables. A simple testcase demonstrating it on an x86_64 is for
example the following:
$ cat cond_store.c
int g_1 = 1;
int g_2[1024] __attribute__((section ("safe_section"), aligned (4096)));
int c = 4;
int __attribute__ ((noinline))
foo (void)
{
int l;
for (l = 0; (l != 4); l++) {
if (g_1)
return l;
for (g_2[0] = 0; (g_2[0] >= 26); ++g_2[0])
;
}
return 2;
}
int main (int argc, char* argv[])
{
if (mprotect (g_2, sizeof(g_2), PROT_READ) == -1)
{
int e = errno;
error (e, e, "mprotect error %i", e);
}
foo ();
__builtin_printf("OK\n");
return 0;
}
/* EOF */
$ ~/gcc/trunk/inst/bin/gcc cond_store.c -O2 --param allow-store-data-races=0
$ ./a.out
OK
$ ~/gcc/trunk/inst/bin/gcc cond_store.c -O2 --param allow-store-data-races=1
$ ./a.out
Segmentation fault
The testcase fails the same at least with 4.9, 4.8 and 4.7. Therefore
I would suggest building kernels with this parameter set to zero. I
also agree with Jikos that the default should be changed for -O2. I
have run most of the SPEC 2k6 CPU benchmarks (gamess and dealII
failed, at -O2, not sure why) compiled with and without this option
and did not see any real difference between respective run-times"
Hopefully the default will be changed in newer gccs, but let's force it
for kernel builds so that we are on a safe side even when older gcc are
used.
The code in question was out-of-tree printk-in-NMI (yeah, surprise
suprise, once again) patch written by Petr Mladek, let me quote his
comment from our internal bugzilla:
"I have spent few days investigating inconsistent state of kernel ring buffer.
It went out that it was caused by speculative store generated by
gcc-4.3.4.
The problem is in assembly generated for make_free_space(). The functions is
called the following way:
+ vprintk_emit();
+ log = MAIN_LOG; // with logbuf_lock
or
log = NMI_LOG; // with nmi_logbuf_lock
cont_add(log, ...);
+ cont_flush(log, ...);
+ log_store(log, ...);
+ log_make_free_space(log, ...);
If called with log = NMI_LOG then only nmi_log_* global variables are safe to
modify but the generated code does store also into (main_)log_* global
variables:
<log_make_free_space>:
55 push %rbp
89 f6 mov %esi,%esi
48 8b 05 03 99 51 01 mov 0x1519903(%rip),%rax # ffffffff82620868 <nmi_log_next_id>
44 8b 1d ec 98 51 01 mov 0x15198ec(%rip),%r11d # ffffffff82620858 <log_next_idx>
8b 35 36 60 14 01 mov 0x1146036(%rip),%esi # ffffffff8224cfa8 <log_buf_len>
44 8b 35 33 60 14 01 mov 0x1146033(%rip),%r14d # ffffffff8224cfac <nmi_log_buf_len>
4c 8b 2d d0 98 51 01 mov 0x15198d0(%rip),%r13 # ffffffff82620850 <log_next_seq>
4c 8b 25 11 61 14 01 mov 0x1146111(%rip),%r12 # ffffffff8224d098 <log_buf>
49 89 c2 mov %rax,%r10
48 21 c2 and %rax,%rdx
48 8b 1d 0c 99 55 01 mov 0x155990c(%rip),%rbx # ffffffff826608a0 <nmi_log_buf>
49 c1 ea 20 shr $0x20,%r10
48 89 55 d0 mov %rdx,-0x30(%rbp)
44 29 de sub %r11d,%esi
45 29 d6 sub %r10d,%r14d
4c 8b 0d 97 98 51 01 mov 0x1519897(%rip),%r9 # ffffffff82620840 <log_first_seq>
eb 7e jmp ffffffff81107029 <log_make_free_space+0xe9>
[...]
85 ff test %edi,%edi # edi = 1 for NMI_LOG
4c 89 e8 mov %r13,%rax
4c 89 ca mov %r9,%rdx
74 0a je ffffffff8110703d <log_make_free_space+0xfd>
8b 15 27 98 51 01 mov 0x1519827(%rip),%edx # ffffffff82620860 <nmi_log_first_id>
48 8b 45 d0 mov -0x30(%rbp),%rax
48 39 c2 cmp %rax,%rdx # end of loop
0f 84 da 00 00 00 je ffffffff81107120 <log_make_free_space+0x1e0>
[...]
85 ff test %edi,%edi # edi = 1 for NMI_LOG
4c 89 0d 17 97 51 01 mov %r9,0x1519717(%rip) # ffffffff82620840 <log_first_seq>
^^^^^^^^^^^^^^^^^^^^^^^^^^
KABOOOM
74 35 je ffffffff81107160 <log_make_free_space+0x220>
It stores log_first_seq when edi == NMI_LOG. This instructions are used also
when edi == MAIN_LOG but the store is done speculatively before the condition
is decided. It is unsafe because we do not have "logbuf_lock" in NMI context
and some other process migh modify "log_first_seq" in parallel"
I believe that the best course of action is both
- building kernel (and anything multi-threaded, I guess) with that
optimization turned off
- persuade gcc folks to change the default for future releases
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Cc: Martin Jambor <mjambor@suse.cz>
Cc: Petr Mladek <pmladek@suse.cz>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Marek Polacek <polacek@redhat.com>
Cc: Jakub Jelinek <jakub@redhat.com>
Cc: Steven Noonan <steven@uplinklabs.net>
Cc: Richard Biener <richard.guenther@gmail.com>
Cc: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-08-06 23:08:43 +00:00
|
|
|
|
2012-03-28 18:51:18 +00:00
|
|
|
ifdef CONFIG_READABLE_ASM
|
|
|
|
|
# Disable optimizations that make assembler listings hard to read.
|
|
|
|
|
# reorder blocks reorders the control in the function
|
|
|
|
|
# ipa clone creates specialized cloned functions
|
|
|
|
|
# partial inlining inlines only parts of functions
|
Makefile: remove stale cc-option checks
cc-option, cc-option-yn, and cc-disable-warning all invoke the compiler
during build time, and can slow down the build when these checks become
stale for our supported compilers, whose minimally supported versions
increases over time. See Documentation/process/changes.rst for the
current supported minimal versions (GCC 4.9+, clang 10.0.1+). Compiler
version support for these flags may be verified on godbolt.org.
The following flags are GCC only and supported since at least GCC 4.9.
Remove cc-option and cc-disable-warning tests.
* -fno-tree-loop-im
* -Wno-maybe-uninitialized
* -fno-reorder-blocks
* -fno-ipa-cp-clone
* -fno-partial-inlining
* -femit-struct-debug-baseonly
* -fno-inline-functions-called-once
* -fconserve-stack
The following flags are supported by all supported versions of GCC and
Clang. Remove their cc-option, cc-option-yn, and cc-disable-warning tests.
* -fno-delete-null-pointer-checks
* -fno-var-tracking
* -Wno-array-bounds
The following configs are made dependent on GCC, since they use GCC
specific flags.
* READABLE_ASM
* DEBUG_SECTION_MISMATCH
-mfentry was not supported by s390-linux-gnu-gcc until gcc-9+, add a
comment.
--param=allow-store-data-races=0 was renamed to -fno-allow-store-data-races
in the GCC 10 release; add a comment.
-Wmaybe-uninitialized (GCC specific) was being added for CONFIG_GCOV,
then again unconditionally; add it only once.
Also, base RETPOLINE_CFLAGS and RETPOLINE_VDSO_CFLAGS on CONFIC_CC_IS_*
then remove cc-option tests for Clang.
Link: https://github.com/ClangBuiltLinux/linux/issues/1436
Acked-by: Miguel Ojeda <ojeda@kernel.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2021-08-16 20:25:01 +00:00
|
|
|
KBUILD_CFLAGS += -fno-reorder-blocks -fno-ipa-cp-clone -fno-partial-inlining
|
2012-03-28 18:51:18 +00:00
|
|
|
endif
|
|
|
|
|
|
2020-06-26 18:59:12 +00:00
|
|
|
stackp-flags-y := -fno-stack-protector
|
Kbuild: rename CC_STACKPROTECTOR[_STRONG] config variables
The changes to automatically test for working stack protector compiler
support in the Kconfig files removed the special STACKPROTECTOR_AUTO
option that picked the strongest stack protector that the compiler
supported.
That was all a nice cleanup - it makes no sense to have the AUTO case
now that the Kconfig phase can just determine the compiler support
directly.
HOWEVER.
It also meant that doing "make oldconfig" would now _disable_ the strong
stackprotector if you had AUTO enabled, because in a legacy config file,
the sane stack protector configuration would look like
CONFIG_HAVE_CC_STACKPROTECTOR=y
# CONFIG_CC_STACKPROTECTOR_NONE is not set
# CONFIG_CC_STACKPROTECTOR_REGULAR is not set
# CONFIG_CC_STACKPROTECTOR_STRONG is not set
CONFIG_CC_STACKPROTECTOR_AUTO=y
and when you ran this through "make oldconfig" with the Kbuild changes,
it would ask you about the regular CONFIG_CC_STACKPROTECTOR (that had
been renamed from CONFIG_CC_STACKPROTECTOR_REGULAR to just
CONFIG_CC_STACKPROTECTOR), but it would think that the STRONG version
used to be disabled (because it was really enabled by AUTO), and would
disable it in the new config, resulting in:
CONFIG_HAVE_CC_STACKPROTECTOR=y
CONFIG_CC_HAS_STACKPROTECTOR_NONE=y
CONFIG_CC_STACKPROTECTOR=y
# CONFIG_CC_STACKPROTECTOR_STRONG is not set
CONFIG_CC_HAS_SANE_STACKPROTECTOR=y
That's dangerously subtle - people could suddenly find themselves with
the weaker stack protector setup without even realizing.
The solution here is to just rename not just the old RECULAR stack
protector option, but also the strong one. This does that by just
removing the CC_ prefix entirely for the user choices, because it really
is not about the compiler support (the compiler support now instead
automatially impacts _visibility_ of the options to users).
This results in "make oldconfig" actually asking the user for their
choice, so that we don't have any silent subtle security model changes.
The end result would generally look like this:
CONFIG_HAVE_CC_STACKPROTECTOR=y
CONFIG_CC_HAS_STACKPROTECTOR_NONE=y
CONFIG_STACKPROTECTOR=y
CONFIG_STACKPROTECTOR_STRONG=y
CONFIG_CC_HAS_SANE_STACKPROTECTOR=y
where the "CC_" versions really are about internal compiler
infrastructure, not the user selections.
Acked-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2018-06-14 03:21:18 +00:00
|
|
|
stackp-flags-$(CONFIG_STACKPROTECTOR) := -fstack-protector
|
|
|
|
|
stackp-flags-$(CONFIG_STACKPROTECTOR_STRONG) := -fstack-protector-strong
|
stack-protector: test compiler capability in Kconfig and drop AUTO mode
Move the test for -fstack-protector(-strong) option to Kconfig.
If the compiler does not support the option, the corresponding menu
is automatically hidden. If STRONG is not supported, it will fall
back to REGULAR. If REGULAR is not supported, it will be disabled.
This means, AUTO is implicitly handled by the dependency solver of
Kconfig, hence removed.
I also turned the 'choice' into only two boolean symbols. The use of
'choice' is not a good idea here, because all of all{yes,mod,no}config
would choose the first visible value, while we want allnoconfig to
disable as many features as possible.
X86 has additional shell scripts in case the compiler supports those
options, but generates broken code. I added CC_HAS_SANE_STACKPROTECTOR
to test this. I had to add -m32 to gcc-x86_32-has-stack-protector.sh
to make it work correctly.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Kees Cook <keescook@chromium.org>
2018-05-28 09:22:00 +00:00
|
|
|
|
|
|
|
|
KBUILD_CFLAGS += $(stackp-flags-y)
|
2008-02-13 21:43:28 +00:00
|
|
|
|
2021-07-03 14:42:57 +00:00
|
|
|
KBUILD_RUSTFLAGS-$(CONFIG_WERROR) += -Dwarnings
|
|
|
|
|
KBUILD_RUSTFLAGS += $(KBUILD_RUSTFLAGS-y)
|
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
ifdef CONFIG_FRAME_POINTER
|
2007-10-14 20:21:35 +00:00
|
|
|
KBUILD_CFLAGS += -fno-omit-frame-pointer -fno-optimize-sibling-calls
|
2021-07-03 14:42:57 +00:00
|
|
|
KBUILD_RUSTFLAGS += -Cforce-frame-pointers=y
|
2005-04-16 22:20:36 +00:00
|
|
|
else
|
2010-08-10 18:20:53 +00:00
|
|
|
# Some targets (ARM with Thumb2, for example), can't be built with frame
|
|
|
|
|
# pointers. For those, we don't have FUNCTION_TRACER automatically
|
|
|
|
|
# select FRAME_POINTER. However, FUNCTION_TRACER adds -pg, and this is
|
|
|
|
|
# incompatible with -fomit-frame-pointer with current GCC, so we don't use
|
|
|
|
|
# -fomit-frame-pointer with FUNCTION_TRACER.
|
2021-07-03 14:42:57 +00:00
|
|
|
# In the Rust target specification, "frame-pointer" is set explicitly
|
|
|
|
|
# to "may-omit".
|
2010-08-10 18:20:53 +00:00
|
|
|
ifndef CONFIG_FUNCTION_TRACER
|
2007-10-14 20:21:35 +00:00
|
|
|
KBUILD_CFLAGS += -fomit-frame-pointer
|
2005-04-16 22:20:36 +00:00
|
|
|
endif
|
2010-08-10 18:20:53 +00:00
|
|
|
endif
|
2005-04-16 22:20:36 +00:00
|
|
|
|
security: allow using Clang's zero initialization for stack variables
In addition to -ftrivial-auto-var-init=pattern (used by
CONFIG_INIT_STACK_ALL now) Clang also supports zero initialization for
locals enabled by -ftrivial-auto-var-init=zero. The future of this flag
is still being debated (see https://bugs.llvm.org/show_bug.cgi?id=45497).
Right now it is guarded by another flag,
-enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang,
which means it may not be supported by future Clang releases. Another
possible resolution is that -ftrivial-auto-var-init=zero will persist
(as certain users have already started depending on it), but the name
of the guard flag will change.
In the meantime, zero initialization has proven itself as a good
production mitigation measure against uninitialized locals. Unlike pattern
initialization, which has a higher chance of triggering existing bugs,
zero initialization provides safe defaults for strings, pointers, indexes,
and sizes. On the other hand, pattern initialization remains safer for
return values. Chrome OS and Android are moving to using zero
initialization for production builds.
Performance-wise, the difference between pattern and zero initialization
is usually negligible, although the generated code for zero
initialization is more compact.
This patch renames CONFIG_INIT_STACK_ALL to CONFIG_INIT_STACK_ALL_PATTERN
and introduces another config option, CONFIG_INIT_STACK_ALL_ZERO, that
enables zero initialization for locals if the corresponding flags are
supported by Clang.
Cc: Kees Cook <keescook@chromium.org>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Alexander Potapenko <glider@google.com>
Link: https://lore.kernel.org/r/20200616083435.223038-1-glider@google.com
Reviewed-by: Maciej Żenczykowski <maze@google.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
2020-06-16 08:34:35 +00:00
|
|
|
# Initialize all stack variables with a 0xAA pattern.
|
|
|
|
|
ifdef CONFIG_INIT_STACK_ALL_PATTERN
|
2019-04-10 15:48:31 +00:00
|
|
|
KBUILD_CFLAGS += -ftrivial-auto-var-init=pattern
|
|
|
|
|
endif
|
|
|
|
|
|
security: allow using Clang's zero initialization for stack variables
In addition to -ftrivial-auto-var-init=pattern (used by
CONFIG_INIT_STACK_ALL now) Clang also supports zero initialization for
locals enabled by -ftrivial-auto-var-init=zero. The future of this flag
is still being debated (see https://bugs.llvm.org/show_bug.cgi?id=45497).
Right now it is guarded by another flag,
-enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang,
which means it may not be supported by future Clang releases. Another
possible resolution is that -ftrivial-auto-var-init=zero will persist
(as certain users have already started depending on it), but the name
of the guard flag will change.
In the meantime, zero initialization has proven itself as a good
production mitigation measure against uninitialized locals. Unlike pattern
initialization, which has a higher chance of triggering existing bugs,
zero initialization provides safe defaults for strings, pointers, indexes,
and sizes. On the other hand, pattern initialization remains safer for
return values. Chrome OS and Android are moving to using zero
initialization for production builds.
Performance-wise, the difference between pattern and zero initialization
is usually negligible, although the generated code for zero
initialization is more compact.
This patch renames CONFIG_INIT_STACK_ALL to CONFIG_INIT_STACK_ALL_PATTERN
and introduces another config option, CONFIG_INIT_STACK_ALL_ZERO, that
enables zero initialization for locals if the corresponding flags are
supported by Clang.
Cc: Kees Cook <keescook@chromium.org>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Alexander Potapenko <glider@google.com>
Link: https://lore.kernel.org/r/20200616083435.223038-1-glider@google.com
Reviewed-by: Maciej Żenczykowski <maze@google.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
2020-06-16 08:34:35 +00:00
|
|
|
# Initialize all stack variables with a zero value.
|
|
|
|
|
ifdef CONFIG_INIT_STACK_ALL_ZERO
|
|
|
|
|
KBUILD_CFLAGS += -ftrivial-auto-var-init=zero
|
2022-09-30 05:57:43 +00:00
|
|
|
ifdef CONFIG_CC_HAS_AUTO_VAR_INIT_ZERO_ENABLER
|
|
|
|
|
# https://github.com/llvm/llvm-project/issues/44842
|
2023-01-24 16:19:28 +00:00
|
|
|
CC_AUTO_VAR_INIT_ZERO_ENABLER := -enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang
|
|
|
|
|
export CC_AUTO_VAR_INIT_ZERO_ENABLER
|
|
|
|
|
KBUILD_CFLAGS += $(CC_AUTO_VAR_INIT_ZERO_ENABLER)
|
security: allow using Clang's zero initialization for stack variables
In addition to -ftrivial-auto-var-init=pattern (used by
CONFIG_INIT_STACK_ALL now) Clang also supports zero initialization for
locals enabled by -ftrivial-auto-var-init=zero. The future of this flag
is still being debated (see https://bugs.llvm.org/show_bug.cgi?id=45497).
Right now it is guarded by another flag,
-enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang,
which means it may not be supported by future Clang releases. Another
possible resolution is that -ftrivial-auto-var-init=zero will persist
(as certain users have already started depending on it), but the name
of the guard flag will change.
In the meantime, zero initialization has proven itself as a good
production mitigation measure against uninitialized locals. Unlike pattern
initialization, which has a higher chance of triggering existing bugs,
zero initialization provides safe defaults for strings, pointers, indexes,
and sizes. On the other hand, pattern initialization remains safer for
return values. Chrome OS and Android are moving to using zero
initialization for production builds.
Performance-wise, the difference between pattern and zero initialization
is usually negligible, although the generated code for zero
initialization is more compact.
This patch renames CONFIG_INIT_STACK_ALL to CONFIG_INIT_STACK_ALL_PATTERN
and introduces another config option, CONFIG_INIT_STACK_ALL_ZERO, that
enables zero initialization for locals if the corresponding flags are
supported by Clang.
Cc: Kees Cook <keescook@chromium.org>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Alexander Potapenko <glider@google.com>
Link: https://lore.kernel.org/r/20200616083435.223038-1-glider@google.com
Reviewed-by: Maciej Żenczykowski <maze@google.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
2020-06-16 08:34:35 +00:00
|
|
|
endif
|
2021-09-14 19:49:03 +00:00
|
|
|
endif
|
security: allow using Clang's zero initialization for stack variables
In addition to -ftrivial-auto-var-init=pattern (used by
CONFIG_INIT_STACK_ALL now) Clang also supports zero initialization for
locals enabled by -ftrivial-auto-var-init=zero. The future of this flag
is still being debated (see https://bugs.llvm.org/show_bug.cgi?id=45497).
Right now it is guarded by another flag,
-enable-trivial-auto-var-init-zero-knowing-it-will-be-removed-from-clang,
which means it may not be supported by future Clang releases. Another
possible resolution is that -ftrivial-auto-var-init=zero will persist
(as certain users have already started depending on it), but the name
of the guard flag will change.
In the meantime, zero initialization has proven itself as a good
production mitigation measure against uninitialized locals. Unlike pattern
initialization, which has a higher chance of triggering existing bugs,
zero initialization provides safe defaults for strings, pointers, indexes,
and sizes. On the other hand, pattern initialization remains safer for
return values. Chrome OS and Android are moving to using zero
initialization for production builds.
Performance-wise, the difference between pattern and zero initialization
is usually negligible, although the generated code for zero
initialization is more compact.
This patch renames CONFIG_INIT_STACK_ALL to CONFIG_INIT_STACK_ALL_PATTERN
and introduces another config option, CONFIG_INIT_STACK_ALL_ZERO, that
enables zero initialization for locals if the corresponding flags are
supported by Clang.
Cc: Kees Cook <keescook@chromium.org>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Signed-off-by: Alexander Potapenko <glider@google.com>
Link: https://lore.kernel.org/r/20200616083435.223038-1-glider@google.com
Reviewed-by: Maciej Żenczykowski <maze@google.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
2020-06-16 08:34:35 +00:00
|
|
|
|
stack: Optionally randomize kernel stack offset each syscall
This provides the ability for architectures to enable kernel stack base
address offset randomization. This feature is controlled by the boot
param "randomize_kstack_offset=on/off", with its default value set by
CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT.
This feature is based on the original idea from the last public release
of PaX's RANDKSTACK feature: https://pax.grsecurity.net/docs/randkstack.txt
All the credit for the original idea goes to the PaX team. Note that
the design and implementation of this upstream randomize_kstack_offset
feature differs greatly from the RANDKSTACK feature (see below).
Reasoning for the feature:
This feature aims to make harder the various stack-based attacks that
rely on deterministic stack structure. We have had many such attacks in
past (just to name few):
https://jon.oberheide.org/files/infiltrate12-thestackisback.pdf
https://jon.oberheide.org/files/stackjacking-infiltrate11.pdf
https://googleprojectzero.blogspot.com/2016/06/exploiting-recursion-in-linux-kernel_20.html
As Linux kernel stack protections have been constantly improving
(vmap-based stack allocation with guard pages, removal of thread_info,
STACKLEAK), attackers have had to find new ways for their exploits
to work. They have done so, continuing to rely on the kernel's stack
determinism, in situations where VMAP_STACK and THREAD_INFO_IN_TASK_STRUCT
were not relevant. For example, the following recent attacks would have
been hampered if the stack offset was non-deterministic between syscalls:
https://repositorio-aberto.up.pt/bitstream/10216/125357/2/374717.pdf
(page 70: targeting the pt_regs copy with linear stack overflow)
https://a13xp0p0v.github.io/2020/02/15/CVE-2019-18683.html
(leaked stack address from one syscall as a target during next syscall)
The main idea is that since the stack offset is randomized on each system
call, it is harder for an attack to reliably land in any particular place
on the thread stack, even with address exposures, as the stack base will
change on the next syscall. Also, since randomization is performed after
placing pt_regs, the ptrace-based approach[1] to discover the randomized
offset during a long-running syscall should not be possible.
Design description:
During most of the kernel's execution, it runs on the "thread stack",
which is pretty deterministic in its structure: it is fixed in size,
and on every entry from userspace to kernel on a syscall the thread
stack starts construction from an address fetched from the per-cpu
cpu_current_top_of_stack variable. The first element to be pushed to the
thread stack is the pt_regs struct that stores all required CPU registers
and syscall parameters. Finally the specific syscall function is called,
with the stack being used as the kernel executes the resulting request.
The goal of randomize_kstack_offset feature is to add a random offset
after the pt_regs has been pushed to the stack and before the rest of the
thread stack is used during the syscall processing, and to change it every
time a process issues a syscall. The source of randomness is currently
architecture-defined (but x86 is using the low byte of rdtsc()). Future
improvements for different entropy sources is possible, but out of scope
for this patch. Further more, to add more unpredictability, new offsets
are chosen at the end of syscalls (the timing of which should be less
easy to measure from userspace than at syscall entry time), and stored
in a per-CPU variable, so that the life of the value does not stay
explicitly tied to a single task.
As suggested by Andy Lutomirski, the offset is added using alloca()
and an empty asm() statement with an output constraint, since it avoids
changes to assembly syscall entry code, to the unwinder, and provides
correct stack alignment as defined by the compiler.
In order to make this available by default with zero performance impact
for those that don't want it, it is boot-time selectable with static
branches. This way, if the overhead is not wanted, it can just be
left turned off with no performance impact.
The generated assembly for x86_64 with GCC looks like this:
...
ffffffff81003977: 65 8b 05 02 ea 00 7f mov %gs:0x7f00ea02(%rip),%eax
# 12380 <kstack_offset>
ffffffff8100397e: 25 ff 03 00 00 and $0x3ff,%eax
ffffffff81003983: 48 83 c0 0f add $0xf,%rax
ffffffff81003987: 25 f8 07 00 00 and $0x7f8,%eax
ffffffff8100398c: 48 29 c4 sub %rax,%rsp
ffffffff8100398f: 48 8d 44 24 0f lea 0xf(%rsp),%rax
ffffffff81003994: 48 83 e0 f0 and $0xfffffffffffffff0,%rax
...
As a result of the above stack alignment, this patch introduces about
5 bits of randomness after pt_regs is spilled to the thread stack on
x86_64, and 6 bits on x86_32 (since its has 1 fewer bit required for
stack alignment). The amount of entropy could be adjusted based on how
much of the stack space we wish to trade for security.
My measure of syscall performance overhead (on x86_64):
lmbench: /usr/lib/lmbench/bin/x86_64-linux-gnu/lat_syscall -N 10000 null
randomize_kstack_offset=y Simple syscall: 0.7082 microseconds
randomize_kstack_offset=n Simple syscall: 0.7016 microseconds
So, roughly 0.9% overhead growth for a no-op syscall, which is very
manageable. And for people that don't want this, it's off by default.
There are two gotchas with using the alloca() trick. First,
compilers that have Stack Clash protection (-fstack-clash-protection)
enabled by default (e.g. Ubuntu[3]) add pagesize stack probes to
any dynamic stack allocations. While the randomization offset is
always less than a page, the resulting assembly would still contain
(unreachable!) probing routines, bloating the resulting assembly. To
avoid this, -fno-stack-clash-protection is unconditionally added to
the kernel Makefile since this is the only dynamic stack allocation in
the kernel (now that VLAs have been removed) and it is provably safe
from Stack Clash style attacks.
The second gotcha with alloca() is a negative interaction with
-fstack-protector*, in that it sees the alloca() as an array allocation,
which triggers the unconditional addition of the stack canary function
pre/post-amble which slows down syscalls regardless of the static
branch. In order to avoid adding this unneeded check and its associated
performance impact, architectures need to carefully remove uses of
-fstack-protector-strong (or -fstack-protector) in the compilation units
that use the add_random_kstack() macro and to audit the resulting stack
mitigation coverage (to make sure no desired coverage disappears). No
change is visible for this on x86 because the stack protector is already
unconditionally disabled for the compilation unit, but the change is
required on arm64. There is, unfortunately, no attribute that can be
used to disable stack protector for specific functions.
Comparison to PaX RANDKSTACK feature:
The RANDKSTACK feature randomizes the location of the stack start
(cpu_current_top_of_stack), i.e. including the location of pt_regs
structure itself on the stack. Initially this patch followed the same
approach, but during the recent discussions[2], it has been determined
to be of a little value since, if ptrace functionality is available for
an attacker, they can use PTRACE_PEEKUSR/PTRACE_POKEUSR to read/write
different offsets in the pt_regs struct, observe the cache behavior of
the pt_regs accesses, and figure out the random stack offset. Another
difference is that the random offset is stored in a per-cpu variable,
rather than having it be per-thread. As a result, these implementations
differ a fair bit in their implementation details and results, though
obviously the intent is similar.
[1] https://lore.kernel.org/kernel-hardening/2236FBA76BA1254E88B949DDB74E612BA4BC57C1@IRSMSX102.ger.corp.intel.com/
[2] https://lore.kernel.org/kernel-hardening/20190329081358.30497-1-elena.reshetova@intel.com/
[3] https://lists.ubuntu.com/archives/ubuntu-devel/2019-June/040741.html
Co-developed-by: Elena Reshetova <elena.reshetova@intel.com>
Signed-off-by: Elena Reshetova <elena.reshetova@intel.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Link: https://lore.kernel.org/r/20210401232347.2791257-4-keescook@chromium.org
2021-04-01 23:23:44 +00:00
|
|
|
# While VLAs have been removed, GCC produces unreachable stack probes
|
|
|
|
|
# for the randomize_kstack_offset feature. Disable it for all compilers.
|
|
|
|
|
KBUILD_CFLAGS += $(call cc-option, -fno-stack-clash-protection)
|
|
|
|
|
|
hardening: Introduce CONFIG_ZERO_CALL_USED_REGS
When CONFIG_ZERO_CALL_USED_REGS is enabled, build the kernel with
"-fzero-call-used-regs=used-gpr" (in GCC 11). This option will zero any
caller-used register contents just before returning from a function,
ensuring that temporary values are not leaked beyond the function
boundary. This means that register contents are less likely to be
available for side channel attacks and information exposures.
Additionally this helps reduce the number of useful ROP gadgets in the
kernel image by about 20%:
$ ROPgadget.py --nosys --nojop --binary vmlinux.stock | tail -n1
Unique gadgets found: 337245
$ ROPgadget.py --nosys --nojop --binary vmlinux.zero-call-regs | tail -n1
Unique gadgets found: 267175
and more notably removes simple "write-what-where" gadgets:
$ ROPgadget.py --ropchain --binary vmlinux.stock | sed -n '/Step 1/,/Step 2/p'
- Step 1 -- Write-what-where gadgets
[+] Gadget found: 0xffffffff8102d76c mov qword ptr [rsi], rdx ; ret
[+] Gadget found: 0xffffffff81000cf5 pop rsi ; ret
[+] Gadget found: 0xffffffff8104d7c8 pop rdx ; ret
[-] Can't find the 'xor rdx, rdx' gadget. Try with another 'mov [reg], reg'
[+] Gadget found: 0xffffffff814c2b4c mov qword ptr [rsi], rdi ; ret
[+] Gadget found: 0xffffffff81000cf5 pop rsi ; ret
[+] Gadget found: 0xffffffff81001e51 pop rdi ; ret
[-] Can't find the 'xor rdi, rdi' gadget. Try with another 'mov [reg], reg'
[+] Gadget found: 0xffffffff81540d61 mov qword ptr [rsi], rdi ; pop rbx ; pop rbp ; ret
[+] Gadget found: 0xffffffff81000cf5 pop rsi ; ret
[+] Gadget found: 0xffffffff81001e51 pop rdi ; ret
[-] Can't find the 'xor rdi, rdi' gadget. Try with another 'mov [reg], reg'
[+] Gadget found: 0xffffffff8105341e mov qword ptr [rsi], rax ; ret
[+] Gadget found: 0xffffffff81000cf5 pop rsi ; ret
[+] Gadget found: 0xffffffff81029a11 pop rax ; ret
[+] Gadget found: 0xffffffff811f1c3b xor rax, rax ; ret
- Step 2 -- Init syscall number gadgets
$ ROPgadget.py --ropchain --binary vmlinux.zero* | sed -n '/Step 1/,/Step 2/p'
- Step 1 -- Write-what-where gadgets
[-] Can't find the 'mov qword ptr [r64], r64' gadget
For an x86_64 parallel build tests, this has a less than 1% performance
impact, and grows the image size less than 1%:
$ size vmlinux.stock vmlinux.zero-call-regs
text data bss dec hex filename
22437676 8559152 14127340 45124168 2b08a48 vmlinux.stock
22453184 8563248 14110956 45127388 2b096dc vmlinux.zero-call-regs
Impact for other architectures may vary. For example, arm64 sees a 5.5%
image size growth, mainly due to needing to always clear x16 and x17:
https://lore.kernel.org/lkml/20210510134503.GA88495@C02TD0UTHF1T.local/
Signed-off-by: Kees Cook <keescook@chromium.org>
2021-04-13 02:56:54 +00:00
|
|
|
# Clear used registers at func exit (to reduce data lifetime and ROP gadgets).
|
|
|
|
|
ifdef CONFIG_ZERO_CALL_USED_REGS
|
|
|
|
|
KBUILD_CFLAGS += -fzero-call-used-regs=used-gpr
|
|
|
|
|
endif
|
|
|
|
|
|
2008-10-06 23:06:12 +00:00
|
|
|
ifdef CONFIG_FUNCTION_TRACER
|
2020-12-11 18:46:18 +00:00
|
|
|
ifdef CONFIG_FTRACE_MCOUNT_USE_CC
|
|
|
|
|
CC_FLAGS_FTRACE += -mrecord-mcount
|
2018-08-06 13:17:46 +00:00
|
|
|
ifdef CONFIG_HAVE_NOP_MCOUNT
|
|
|
|
|
ifeq ($(call cc-option-yn, -mnop-mcount),y)
|
|
|
|
|
CC_FLAGS_FTRACE += -mnop-mcount
|
|
|
|
|
CC_FLAGS_USING += -DCC_USING_NOP_MCOUNT
|
|
|
|
|
endif
|
|
|
|
|
endif
|
2018-08-06 13:17:44 +00:00
|
|
|
endif
|
2020-09-25 23:43:53 +00:00
|
|
|
ifdef CONFIG_FTRACE_MCOUNT_USE_OBJTOOL
|
2022-11-14 17:57:49 +00:00
|
|
|
ifdef CONFIG_HAVE_OBJTOOL_NOP_MCOUNT
|
|
|
|
|
CC_FLAGS_USING += -DCC_USING_NOP_MCOUNT
|
|
|
|
|
endif
|
2020-09-25 23:43:53 +00:00
|
|
|
endif
|
2020-12-11 18:46:18 +00:00
|
|
|
ifdef CONFIG_FTRACE_MCOUNT_USE_RECORDMCOUNT
|
|
|
|
|
ifdef CONFIG_HAVE_C_RECORDMCOUNT
|
|
|
|
|
BUILD_C_RECORDMCOUNT := y
|
|
|
|
|
export BUILD_C_RECORDMCOUNT
|
|
|
|
|
endif
|
|
|
|
|
endif
|
2011-02-09 18:15:59 +00:00
|
|
|
ifdef CONFIG_HAVE_FENTRY
|
Makefile: remove stale cc-option checks
cc-option, cc-option-yn, and cc-disable-warning all invoke the compiler
during build time, and can slow down the build when these checks become
stale for our supported compilers, whose minimally supported versions
increases over time. See Documentation/process/changes.rst for the
current supported minimal versions (GCC 4.9+, clang 10.0.1+). Compiler
version support for these flags may be verified on godbolt.org.
The following flags are GCC only and supported since at least GCC 4.9.
Remove cc-option and cc-disable-warning tests.
* -fno-tree-loop-im
* -Wno-maybe-uninitialized
* -fno-reorder-blocks
* -fno-ipa-cp-clone
* -fno-partial-inlining
* -femit-struct-debug-baseonly
* -fno-inline-functions-called-once
* -fconserve-stack
The following flags are supported by all supported versions of GCC and
Clang. Remove their cc-option, cc-option-yn, and cc-disable-warning tests.
* -fno-delete-null-pointer-checks
* -fno-var-tracking
* -Wno-array-bounds
The following configs are made dependent on GCC, since they use GCC
specific flags.
* READABLE_ASM
* DEBUG_SECTION_MISMATCH
-mfentry was not supported by s390-linux-gnu-gcc until gcc-9+, add a
comment.
--param=allow-store-data-races=0 was renamed to -fno-allow-store-data-races
in the GCC 10 release; add a comment.
-Wmaybe-uninitialized (GCC specific) was being added for CONFIG_GCOV,
then again unconditionally; add it only once.
Also, base RETPOLINE_CFLAGS and RETPOLINE_VDSO_CFLAGS on CONFIC_CC_IS_*
then remove cc-option tests for Clang.
Link: https://github.com/ClangBuiltLinux/linux/issues/1436
Acked-by: Miguel Ojeda <ojeda@kernel.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2021-08-16 20:25:01 +00:00
|
|
|
# s390-linux-gnu-gcc did not support -mfentry until gcc-9.
|
2018-08-06 13:17:42 +00:00
|
|
|
ifeq ($(call cc-option-yn, -mfentry),y)
|
|
|
|
|
CC_FLAGS_FTRACE += -mfentry
|
|
|
|
|
CC_FLAGS_USING += -DCC_USING_FENTRY
|
|
|
|
|
endif
|
2011-02-09 18:15:59 +00:00
|
|
|
endif
|
2018-08-06 13:17:42 +00:00
|
|
|
export CC_FLAGS_FTRACE
|
|
|
|
|
KBUILD_CFLAGS += $(CC_FLAGS_FTRACE) $(CC_FLAGS_USING)
|
|
|
|
|
KBUILD_AFLAGS += $(CC_FLAGS_USING)
|
2008-05-12 19:20:42 +00:00
|
|
|
endif
|
|
|
|
|
|
2008-01-21 20:31:44 +00:00
|
|
|
# We trigger additional mismatches with less inlining
|
|
|
|
|
ifdef CONFIG_DEBUG_SECTION_MISMATCH
|
Makefile: remove stale cc-option checks
cc-option, cc-option-yn, and cc-disable-warning all invoke the compiler
during build time, and can slow down the build when these checks become
stale for our supported compilers, whose minimally supported versions
increases over time. See Documentation/process/changes.rst for the
current supported minimal versions (GCC 4.9+, clang 10.0.1+). Compiler
version support for these flags may be verified on godbolt.org.
The following flags are GCC only and supported since at least GCC 4.9.
Remove cc-option and cc-disable-warning tests.
* -fno-tree-loop-im
* -Wno-maybe-uninitialized
* -fno-reorder-blocks
* -fno-ipa-cp-clone
* -fno-partial-inlining
* -femit-struct-debug-baseonly
* -fno-inline-functions-called-once
* -fconserve-stack
The following flags are supported by all supported versions of GCC and
Clang. Remove their cc-option, cc-option-yn, and cc-disable-warning tests.
* -fno-delete-null-pointer-checks
* -fno-var-tracking
* -Wno-array-bounds
The following configs are made dependent on GCC, since they use GCC
specific flags.
* READABLE_ASM
* DEBUG_SECTION_MISMATCH
-mfentry was not supported by s390-linux-gnu-gcc until gcc-9+, add a
comment.
--param=allow-store-data-races=0 was renamed to -fno-allow-store-data-races
in the GCC 10 release; add a comment.
-Wmaybe-uninitialized (GCC specific) was being added for CONFIG_GCOV,
then again unconditionally; add it only once.
Also, base RETPOLINE_CFLAGS and RETPOLINE_VDSO_CFLAGS on CONFIC_CC_IS_*
then remove cc-option tests for Clang.
Link: https://github.com/ClangBuiltLinux/linux/issues/1436
Acked-by: Miguel Ojeda <ojeda@kernel.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2021-08-16 20:25:01 +00:00
|
|
|
KBUILD_CFLAGS += -fno-inline-functions-called-once
|
2008-01-21 20:31:44 +00:00
|
|
|
endif
|
|
|
|
|
|
2021-07-03 14:42:57 +00:00
|
|
|
# `rustc`'s `-Zfunction-sections` applies to data too (as of 1.59.0).
|
2017-04-14 06:17:26 +00:00
|
|
|
ifdef CONFIG_LD_DEAD_CODE_DATA_ELIMINATION
|
2018-08-22 13:51:09 +00:00
|
|
|
KBUILD_CFLAGS_KERNEL += -ffunction-sections -fdata-sections
|
2021-07-03 14:42:57 +00:00
|
|
|
KBUILD_RUSTFLAGS_KERNEL += -Zfunction-sections=y
|
2018-08-22 13:51:09 +00:00
|
|
|
LDFLAGS_vmlinux += --gc-sections
|
2017-04-14 06:17:26 +00:00
|
|
|
endif
|
|
|
|
|
|
2020-04-27 16:00:07 +00:00
|
|
|
ifdef CONFIG_SHADOW_CALL_STACK
|
2022-10-27 15:59:07 +00:00
|
|
|
ifndef CONFIG_DYNAMIC_SCS
|
2020-04-27 16:00:07 +00:00
|
|
|
CC_FLAGS_SCS := -fsanitize=shadow-call-stack
|
|
|
|
|
KBUILD_CFLAGS += $(CC_FLAGS_SCS)
|
2024-08-29 08:22:45 +00:00
|
|
|
KBUILD_RUSTFLAGS += -Zsanitizer=shadow-call-stack
|
2022-10-27 15:59:07 +00:00
|
|
|
endif
|
2020-04-27 16:00:07 +00:00
|
|
|
export CC_FLAGS_SCS
|
|
|
|
|
endif
|
|
|
|
|
|
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
2020-12-11 18:46:19 +00:00
|
|
|
ifdef CONFIG_LTO_CLANG
|
|
|
|
|
ifdef CONFIG_LTO_CLANG_THIN
|
2021-01-21 18:45:55 +00:00
|
|
|
CC_FLAGS_LTO := -flto=thin -fsplit-lto-unit
|
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
2020-12-11 18:46:19 +00:00
|
|
|
else
|
2021-01-21 18:45:55 +00:00
|
|
|
CC_FLAGS_LTO := -flto
|
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
2020-12-11 18:46:19 +00:00
|
|
|
endif
|
|
|
|
|
CC_FLAGS_LTO += -fvisibility=hidden
|
2020-12-11 18:46:21 +00:00
|
|
|
|
|
|
|
|
# Limit inlining across translation units to reduce binary size
|
|
|
|
|
KBUILD_LDFLAGS += -mllvm -import-instr-limit=5
|
2021-06-13 13:07:49 +00:00
|
|
|
endif
|
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
2020-12-11 18:46:19 +00:00
|
|
|
|
|
|
|
|
ifdef CONFIG_LTO
|
2021-02-23 21:59:52 +00:00
|
|
|
KBUILD_CFLAGS += -fno-lto $(CC_FLAGS_LTO)
|
|
|
|
|
KBUILD_AFLAGS += -fno-lto
|
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
2020-12-11 18:46:19 +00:00
|
|
|
export CC_FLAGS_LTO
|
|
|
|
|
endif
|
|
|
|
|
|
add support for Clang CFI
This change adds support for Clang’s forward-edge Control Flow
Integrity (CFI) checking. With CONFIG_CFI_CLANG, the compiler
injects a runtime check before each indirect function call to ensure
the target is a valid function with the correct static type. This
restricts possible call targets and makes it more difficult for
an attacker to exploit bugs that allow the modification of stored
function pointers. For more details, see:
https://clang.llvm.org/docs/ControlFlowIntegrity.html
Clang requires CONFIG_LTO_CLANG to be enabled with CFI to gain
visibility to possible call targets. Kernel modules are supported
with Clang’s cross-DSO CFI mode, which allows checking between
independently compiled components.
With CFI enabled, the compiler injects a __cfi_check() function into
the kernel and each module for validating local call targets. For
cross-module calls that cannot be validated locally, the compiler
calls the global __cfi_slowpath_diag() function, which determines
the target module and calls the correct __cfi_check() function. This
patch includes a slowpath implementation that uses __module_address()
to resolve call targets, and with CONFIG_CFI_CLANG_SHADOW enabled, a
shadow map that speeds up module look-ups by ~3x.
Clang implements indirect call checking using jump tables and
offers two methods of generating them. With canonical jump tables,
the compiler renames each address-taken function to <function>.cfi
and points the original symbol to a jump table entry, which passes
__cfi_check() validation. This isn’t compatible with stand-alone
assembly code, which the compiler doesn’t instrument, and would
result in indirect calls to assembly code to fail. Therefore, we
default to using non-canonical jump tables instead, where the compiler
generates a local jump table entry <function>.cfi_jt for each
address-taken function, and replaces all references to the function
with the address of the jump table entry.
Note that because non-canonical jump table addresses are local
to each component, they break cross-module function address
equality. Specifically, the address of a global function will be
different in each module, as it's replaced with the address of a local
jump table entry. If this address is passed to a different module,
it won’t match the address of the same function taken there. This
may break code that relies on comparing addresses passed from other
components.
CFI checking can be disabled in a function with the __nocfi attribute.
Additionally, CFI can be disabled for an entire compilation unit by
filtering out CC_FLAGS_CFI.
By default, CFI failures result in a kernel panic to stop a potential
exploit. CONFIG_CFI_PERMISSIVE enables a permissive mode, where the
kernel prints out a rate-limited warning instead, and allows execution
to continue. This option is helpful for locating type mismatches, but
should only be enabled during development.
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Tested-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20210408182843.1754385-2-samitolvanen@google.com
2021-04-08 18:28:26 +00:00
|
|
|
ifdef CONFIG_CFI_CLANG
|
2022-09-08 21:54:47 +00:00
|
|
|
CC_FLAGS_CFI := -fsanitize=kcfi
|
cfi: add CONFIG_CFI_ICALL_NORMALIZE_INTEGERS
Introduce a Kconfig option for enabling the experimental option to
normalize integer types. This ensures that integer types of the same
size and signedness are considered compatible by the Control Flow
Integrity sanitizer.
The security impact of this flag is minimal. When Sami Tolvanen looked
into it, he found that integer normalization reduced the number of
unique type hashes in the kernel by ~1%, which is acceptable.
This option exists for compatibility with Rust, as C and Rust do not
have the same set of integer types. There are cases where C has two
different integer types of the same size and signedness, but Rust only
has one integer type of that size and signedness. When Rust calls into
C functions using such types in their signature, this results in CFI
failures. One example is 'unsigned long long' and 'unsigned long' which
are both 64-bit on LP64 targets, so on those targets this flag will give
both types the same CFI tag.
This flag changes the ABI heavily. It is not applied automatically when
CONFIG_RUST is turned on to make sure that the CONFIG_RUST option does
not change the ABI of C code. For example, some build may need to make
other changes atomically with toggling this flag. Having it be a
separate option makes it possible to first turn on normalized integer
tags, and then later turn on CONFIG_RUST.
Similarly, when turning on CONFIG_RUST in a build, you may need a few
attempts where the RUST=y commit gets reverted a few times. It is
inconvenient if reverting RUST=y also requires reverting the changes you
made to support normalized integer tags.
To avoid having this flag impact builds that don't care about this, the
next patch in this series will make CONFIG_RUST turn on this option
using `select` rather than `depends on`.
Signed-off-by: Alice Ryhl <aliceryhl@google.com>
Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
Tested-by: Gatlin Newhouse <gatlin.newhouse@gmail.com>
Acked-by: Kees Cook <kees@kernel.org>
Acked-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lore.kernel.org/r/20240801-kcfi-v2-1-c93caed3d121@google.com
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-08-01 13:35:17 +00:00
|
|
|
ifdef CONFIG_CFI_ICALL_NORMALIZE_INTEGERS
|
|
|
|
|
CC_FLAGS_CFI += -fsanitize-cfi-icall-experimental-normalize-integers
|
|
|
|
|
endif
|
2024-09-12 19:00:44 +00:00
|
|
|
ifdef CONFIG_RUST
|
|
|
|
|
# Always pass -Zsanitizer-cfi-normalize-integers as CONFIG_RUST selects
|
|
|
|
|
# CONFIG_CFI_ICALL_NORMALIZE_INTEGERS.
|
|
|
|
|
RUSTC_FLAGS_CFI := -Zsanitizer=kcfi -Zsanitizer-cfi-normalize-integers
|
|
|
|
|
KBUILD_RUSTFLAGS += $(RUSTC_FLAGS_CFI)
|
|
|
|
|
export RUSTC_FLAGS_CFI
|
|
|
|
|
endif
|
add support for Clang CFI
This change adds support for Clang’s forward-edge Control Flow
Integrity (CFI) checking. With CONFIG_CFI_CLANG, the compiler
injects a runtime check before each indirect function call to ensure
the target is a valid function with the correct static type. This
restricts possible call targets and makes it more difficult for
an attacker to exploit bugs that allow the modification of stored
function pointers. For more details, see:
https://clang.llvm.org/docs/ControlFlowIntegrity.html
Clang requires CONFIG_LTO_CLANG to be enabled with CFI to gain
visibility to possible call targets. Kernel modules are supported
with Clang’s cross-DSO CFI mode, which allows checking between
independently compiled components.
With CFI enabled, the compiler injects a __cfi_check() function into
the kernel and each module for validating local call targets. For
cross-module calls that cannot be validated locally, the compiler
calls the global __cfi_slowpath_diag() function, which determines
the target module and calls the correct __cfi_check() function. This
patch includes a slowpath implementation that uses __module_address()
to resolve call targets, and with CONFIG_CFI_CLANG_SHADOW enabled, a
shadow map that speeds up module look-ups by ~3x.
Clang implements indirect call checking using jump tables and
offers two methods of generating them. With canonical jump tables,
the compiler renames each address-taken function to <function>.cfi
and points the original symbol to a jump table entry, which passes
__cfi_check() validation. This isn’t compatible with stand-alone
assembly code, which the compiler doesn’t instrument, and would
result in indirect calls to assembly code to fail. Therefore, we
default to using non-canonical jump tables instead, where the compiler
generates a local jump table entry <function>.cfi_jt for each
address-taken function, and replaces all references to the function
with the address of the jump table entry.
Note that because non-canonical jump table addresses are local
to each component, they break cross-module function address
equality. Specifically, the address of a global function will be
different in each module, as it's replaced with the address of a local
jump table entry. If this address is passed to a different module,
it won’t match the address of the same function taken there. This
may break code that relies on comparing addresses passed from other
components.
CFI checking can be disabled in a function with the __nocfi attribute.
Additionally, CFI can be disabled for an entire compilation unit by
filtering out CC_FLAGS_CFI.
By default, CFI failures result in a kernel panic to stop a potential
exploit. CONFIG_CFI_PERMISSIVE enables a permissive mode, where the
kernel prints out a rate-limited warning instead, and allows execution
to continue. This option is helpful for locating type mismatches, but
should only be enabled during development.
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
Tested-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Kees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20210408182843.1754385-2-samitolvanen@google.com
2021-04-08 18:28:26 +00:00
|
|
|
KBUILD_CFLAGS += $(CC_FLAGS_CFI)
|
|
|
|
|
export CC_FLAGS_CFI
|
|
|
|
|
endif
|
|
|
|
|
|
2024-03-29 07:18:16 +00:00
|
|
|
# Architectures can define flags to add/remove for floating-point support
|
|
|
|
|
CC_FLAGS_FPU += -D_LINUX_FPU_COMPILATION_UNIT
|
|
|
|
|
export CC_FLAGS_FPU
|
|
|
|
|
export CC_FLAGS_NO_FPU
|
|
|
|
|
|
2022-09-15 11:10:47 +00:00
|
|
|
ifneq ($(CONFIG_FUNCTION_ALIGNMENT),0)
|
2024-02-22 13:35:00 +00:00
|
|
|
# Set the minimal function alignment. Use the newer GCC option
|
|
|
|
|
# -fmin-function-alignment if it is available, or fall back to -falign-funtions.
|
|
|
|
|
# See also CONFIG_CC_HAS_SANE_FUNCTION_ALIGNMENT.
|
|
|
|
|
ifdef CONFIG_CC_HAS_MIN_FUNCTION_ALIGNMENT
|
|
|
|
|
KBUILD_CFLAGS += -fmin-function-alignment=$(CONFIG_FUNCTION_ALIGNMENT)
|
|
|
|
|
else
|
2022-09-15 11:10:47 +00:00
|
|
|
KBUILD_CFLAGS += -falign-functions=$(CONFIG_FUNCTION_ALIGNMENT)
|
./Makefile: add debug option to enable function aligned on 32 bytes
Recently 0day reported many strange performance changes (regression or
improvement), in which there was no obvious relation between the culprit
commit and the benchmark at the first look, and it causes people to doubt
the test itself is wrong.
Upon further check, many of these cases are caused by the change to the
alignment of kernel text or data, as whole text/data of kernel are linked
together, change in one domain may affect alignments of other domains.
gcc has an option '-falign-functions=n' to force text aligned, and with
that option enabled, some of those performance changes will be gone, like
[1][2][3].
Add this option so that developers and 0day can easily find performance
bump caused by text alignment change, as tracking these strange bump is
quite time consuming. Though it can't help in other cases like data
alignment changes like [4].
Following is some size data for v5.7 kernel built with a RHEL config used
in 0day:
text data bss dec filename
19738771 13292906 5554236 38585913 vmlinux.noalign
19758591 13297002 5529660 38585253 vmlinux.align32
Raw vmlinux size in bytes:
v5.7 v5.7+align32
253950832 254018000 +0.02%
Some benchmark data, most of them have no big change:
* hackbench: [ -1.8%, +0.5%]
* fsmark: [ -3.2%, +3.4%] # ext4/xfs/btrfs
* kbuild: [ -2.0%, +0.9%]
* will-it-scale: [ -0.5%, +1.8%] # mmap1/pagefault3
* netperf:
- TCP_CRR [+16.6%, +97.4%]
- TCP_RR [-18.5%, -1.8%]
- TCP_STREAM [ -1.1%, +1.9%]
[1] https://lore.kernel.org/lkml/20200114085637.GA29297@shao2-debian/
[2] https://lore.kernel.org/lkml/20200330011254.GA14393@feng-iot/
[3] https://lore.kernel.org/lkml/1d98d1f0-fe84-6df7-f5bd-f4cb2cdb7f45@intel.com/
[4] https://lore.kernel.org/lkml/20200205123216.GO12867@shao2-debian/
Signed-off-by: Feng Tang <feng.tang@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Cc: Masahiro Yamada <masahiroy@kernel.org>
Cc: Michal Marek <michal.lkml@markovi.net>
Cc: Andi Kleen <andi.kleen@intel.com>
Cc: Huang Ying <ying.huang@intel.com>
Cc: Andy Shevchenko <andriy.shevchenko@intel.com>
Link: http://lkml.kernel.org/r/1595475001-90945-1-git-send-email-feng.tang@intel.com
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-08-12 01:34:13 +00:00
|
|
|
endif
|
2024-02-22 13:35:00 +00:00
|
|
|
endif
|
./Makefile: add debug option to enable function aligned on 32 bytes
Recently 0day reported many strange performance changes (regression or
improvement), in which there was no obvious relation between the culprit
commit and the benchmark at the first look, and it causes people to doubt
the test itself is wrong.
Upon further check, many of these cases are caused by the change to the
alignment of kernel text or data, as whole text/data of kernel are linked
together, change in one domain may affect alignments of other domains.
gcc has an option '-falign-functions=n' to force text aligned, and with
that option enabled, some of those performance changes will be gone, like
[1][2][3].
Add this option so that developers and 0day can easily find performance
bump caused by text alignment change, as tracking these strange bump is
quite time consuming. Though it can't help in other cases like data
alignment changes like [4].
Following is some size data for v5.7 kernel built with a RHEL config used
in 0day:
text data bss dec filename
19738771 13292906 5554236 38585913 vmlinux.noalign
19758591 13297002 5529660 38585253 vmlinux.align32
Raw vmlinux size in bytes:
v5.7 v5.7+align32
253950832 254018000 +0.02%
Some benchmark data, most of them have no big change:
* hackbench: [ -1.8%, +0.5%]
* fsmark: [ -3.2%, +3.4%] # ext4/xfs/btrfs
* kbuild: [ -2.0%, +0.9%]
* will-it-scale: [ -0.5%, +1.8%] # mmap1/pagefault3
* netperf:
- TCP_CRR [+16.6%, +97.4%]
- TCP_RR [-18.5%, -1.8%]
- TCP_STREAM [ -1.1%, +1.9%]
[1] https://lore.kernel.org/lkml/20200114085637.GA29297@shao2-debian/
[2] https://lore.kernel.org/lkml/20200330011254.GA14393@feng-iot/
[3] https://lore.kernel.org/lkml/1d98d1f0-fe84-6df7-f5bd-f4cb2cdb7f45@intel.com/
[4] https://lore.kernel.org/lkml/20200205123216.GO12867@shao2-debian/
Signed-off-by: Feng Tang <feng.tang@intel.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Cc: Masahiro Yamada <masahiroy@kernel.org>
Cc: Michal Marek <michal.lkml@markovi.net>
Cc: Andi Kleen <andi.kleen@intel.com>
Cc: Huang Ying <ying.huang@intel.com>
Cc: Andy Shevchenko <andriy.shevchenko@intel.com>
Link: http://lkml.kernel.org/r/1595475001-90945-1-git-send-email-feng.tang@intel.com
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2020-08-12 01:34:13 +00:00
|
|
|
|
2005-04-30 23:51:42 +00:00
|
|
|
# arch Makefile may override CC so keep this after arch Makefile is included
|
2021-08-02 20:43:15 +00:00
|
|
|
NOSTDINC_FLAGS += -nostdinc
|
2005-04-30 23:51:42 +00:00
|
|
|
|
2023-05-17 23:18:11 +00:00
|
|
|
# To gain proper coverage for CONFIG_UBSAN_BOUNDS and CONFIG_FORTIFY_SOURCE,
|
|
|
|
|
# the kernel uses only C99 flexible arrays for dynamically sized trailing
|
|
|
|
|
# arrays. Enforce this for everything that may examine structure sizes and
|
|
|
|
|
# perform bounds checking.
|
|
|
|
|
KBUILD_CFLAGS += $(call cc-option, -fstrict-flex-arrays=3)
|
|
|
|
|
|
2023-11-30 20:29:34 +00:00
|
|
|
#Currently, disable -Wstringop-overflow for GCC 11, globally.
|
|
|
|
|
KBUILD_CFLAGS-$(CONFIG_CC_NO_STRINGOP_OVERFLOW) += $(call cc-option, -Wno-stringop-overflow)
|
|
|
|
|
KBUILD_CFLAGS-$(CONFIG_CC_STRINGOP_OVERFLOW) += $(call cc-option, -Wstringop-overflow)
|
2023-10-31 23:50:11 +00:00
|
|
|
|
2009-04-09 11:34:34 +00:00
|
|
|
# disable invalid "can't wrap" optimizations for signed / pointers
|
2020-09-10 13:51:17 +00:00
|
|
|
KBUILD_CFLAGS += -fno-strict-overflow
|
2009-03-19 22:53:19 +00:00
|
|
|
|
2017-12-30 01:34:43 +00:00
|
|
|
# Make sure -fstack-check isn't enabled (like gentoo apparently did)
|
2020-09-10 13:51:19 +00:00
|
|
|
KBUILD_CFLAGS += -fno-stack-check
|
2017-12-30 01:34:43 +00:00
|
|
|
|
2009-09-18 19:49:37 +00:00
|
|
|
# conserve stack if available
|
Makefile: remove stale cc-option checks
cc-option, cc-option-yn, and cc-disable-warning all invoke the compiler
during build time, and can slow down the build when these checks become
stale for our supported compilers, whose minimally supported versions
increases over time. See Documentation/process/changes.rst for the
current supported minimal versions (GCC 4.9+, clang 10.0.1+). Compiler
version support for these flags may be verified on godbolt.org.
The following flags are GCC only and supported since at least GCC 4.9.
Remove cc-option and cc-disable-warning tests.
* -fno-tree-loop-im
* -Wno-maybe-uninitialized
* -fno-reorder-blocks
* -fno-ipa-cp-clone
* -fno-partial-inlining
* -femit-struct-debug-baseonly
* -fno-inline-functions-called-once
* -fconserve-stack
The following flags are supported by all supported versions of GCC and
Clang. Remove their cc-option, cc-option-yn, and cc-disable-warning tests.
* -fno-delete-null-pointer-checks
* -fno-var-tracking
* -Wno-array-bounds
The following configs are made dependent on GCC, since they use GCC
specific flags.
* READABLE_ASM
* DEBUG_SECTION_MISMATCH
-mfentry was not supported by s390-linux-gnu-gcc until gcc-9+, add a
comment.
--param=allow-store-data-races=0 was renamed to -fno-allow-store-data-races
in the GCC 10 release; add a comment.
-Wmaybe-uninitialized (GCC specific) was being added for CONFIG_GCOV,
then again unconditionally; add it only once.
Also, base RETPOLINE_CFLAGS and RETPOLINE_VDSO_CFLAGS on CONFIC_CC_IS_*
then remove cc-option tests for Clang.
Link: https://github.com/ClangBuiltLinux/linux/issues/1436
Acked-by: Miguel Ojeda <ojeda@kernel.org>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2021-08-16 20:25:01 +00:00
|
|
|
ifdef CONFIG_CC_IS_GCC
|
|
|
|
|
KBUILD_CFLAGS += -fconserve-stack
|
|
|
|
|
endif
|
2009-09-18 19:49:37 +00:00
|
|
|
|
2024-11-10 01:34:36 +00:00
|
|
|
# change __FILE__ to the relative path to the source directory
|
|
|
|
|
ifdef building_out_of_srctree
|
|
|
|
|
KBUILD_CPPFLAGS += $(call cc-option,-fmacro-prefix-map=$(srcroot)/=)
|
|
|
|
|
endif
|
2018-03-30 04:15:26 +00:00
|
|
|
|
2020-08-01 15:00:49 +00:00
|
|
|
# include additional Makefiles when needed
|
|
|
|
|
include-y := scripts/Makefile.extrawarn
|
2021-10-12 03:25:03 +00:00
|
|
|
include-$(CONFIG_DEBUG_INFO) += scripts/Makefile.debug
|
2023-10-18 15:19:48 +00:00
|
|
|
include-$(CONFIG_DEBUG_INFO_BTF)+= scripts/Makefile.btf
|
2020-08-01 15:00:49 +00:00
|
|
|
include-$(CONFIG_KASAN) += scripts/Makefile.kasan
|
|
|
|
|
include-$(CONFIG_KCSAN) += scripts/Makefile.kcsan
|
2022-09-15 15:03:45 +00:00
|
|
|
include-$(CONFIG_KMSAN) += scripts/Makefile.kmsan
|
2020-08-01 15:00:49 +00:00
|
|
|
include-$(CONFIG_UBSAN) += scripts/Makefile.ubsan
|
|
|
|
|
include-$(CONFIG_KCOV) += scripts/Makefile.kcov
|
2022-05-03 20:55:01 +00:00
|
|
|
include-$(CONFIG_RANDSTRUCT) += scripts/Makefile.randstruct
|
kbuild: Add AutoFDO support for Clang build
Add the build support for using Clang's AutoFDO. Building the kernel
with AutoFDO does not reduce the optimization level from the
compiler. AutoFDO uses hardware sampling to gather information about
the frequency of execution of different code paths within a binary.
This information is then used to guide the compiler's optimization
decisions, resulting in a more efficient binary. Experiments
showed that the kernel can improve up to 10% in latency.
The support requires a Clang compiler after LLVM 17. This submission
is limited to x86 platforms that support PMU features like LBR on
Intel machines and AMD Zen3 BRS. Support for SPE on ARM 1,
and BRBE on ARM 1 is part of planned future work.
Here is an example workflow for AutoFDO kernel:
1) Build the kernel on the host machine with LLVM enabled, for example,
$ make menuconfig LLVM=1
Turn on AutoFDO build config:
CONFIG_AUTOFDO_CLANG=y
With a configuration that has LLVM enabled, use the following
command:
scripts/config -e AUTOFDO_CLANG
After getting the config, build with
$ make LLVM=1
2) Install the kernel on the test machine.
3) Run the load tests. The '-c' option in perf specifies the sample
event period. We suggest using a suitable prime number,
like 500009, for this purpose.
For Intel platforms:
$ perf record -e BR_INST_RETIRED.NEAR_TAKEN:k -a -N -b -c <count> \
-o <perf_file> -- <loadtest>
For AMD platforms:
The supported system are: Zen3 with BRS, or Zen4 with amd_lbr_v2
For Zen3:
$ cat proc/cpuinfo | grep " brs"
For Zen4:
$ cat proc/cpuinfo | grep amd_lbr_v2
$ perf record --pfm-events RETIRED_TAKEN_BRANCH_INSTRUCTIONS:k -a \
-N -b -c <count> -o <perf_file> -- <loadtest>
4) (Optional) Download the raw perf file to the host machine.
5) To generate an AutoFDO profile, two offline tools are available:
create_llvm_prof and llvm_profgen. The create_llvm_prof tool is part
of the AutoFDO project and can be found on GitHub
(https://github.com/google/autofdo), version v0.30.1 or later. The
llvm_profgen tool is included in the LLVM compiler itself. It's
important to note that the version of llvm_profgen doesn't need to
match the version of Clang. It needs to be the LLVM 19 release or
later, or from the LLVM trunk.
$ llvm-profgen --kernel --binary=<vmlinux> --perfdata=<perf_file> \
-o <profile_file>
or
$ create_llvm_prof --binary=<vmlinux> --profile=<perf_file> \
--format=extbinary --out=<profile_file>
Note that multiple AutoFDO profile files can be merged into one via:
$ llvm-profdata merge -o <profile_file> <profile_1> ... <profile_n>
6) Rebuild the kernel using the AutoFDO profile file with the same config
as step 1, (Note CONFIG_AUTOFDO_CLANG needs to be enabled):
$ make LLVM=1 CLANG_AUTOFDO_PROFILE=<profile_file>
Co-developed-by: Han Shen <shenhan@google.com>
Signed-off-by: Han Shen <shenhan@google.com>
Signed-off-by: Rong Xu <xur@google.com>
Suggested-by: Sriraman Tallam <tmsriram@google.com>
Suggested-by: Krzysztof Pszeniczny <kpszeniczny@google.com>
Suggested-by: Nick Desaulniers <ndesaulniers@google.com>
Suggested-by: Stephane Eranian <eranian@google.com>
Tested-by: Yonghong Song <yonghong.song@linux.dev>
Tested-by: Yabin Cui <yabinc@google.com>
Tested-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Kees Cook <kees@kernel.org>
Tested-by: Peter Jung <ptr1337@cachyos.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-11-02 17:51:08 +00:00
|
|
|
include-$(CONFIG_AUTOFDO_CLANG) += scripts/Makefile.autofdo
|
kbuild: Add Propeller configuration for kernel build
Add the build support for using Clang's Propeller optimizer. Like
AutoFDO, Propeller uses hardware sampling to gather information
about the frequency of execution of different code paths within a
binary. This information is then used to guide the compiler's
optimization decisions, resulting in a more efficient binary.
The support requires a Clang compiler LLVM 19 or later, and the
create_llvm_prof tool
(https://github.com/google/autofdo/releases/tag/v0.30.1). This
commit is limited to x86 platforms that support PMU features
like LBR on Intel machines and AMD Zen3 BRS.
Here is an example workflow for building an AutoFDO+Propeller
optimized kernel:
1) Build the kernel on the host machine, with AutoFDO and Propeller
build config
CONFIG_AUTOFDO_CLANG=y
CONFIG_PROPELLER_CLANG=y
then
$ make LLVM=1 CLANG_AUTOFDO_PROFILE=<autofdo_profile>
“<autofdo_profile>” is the profile collected when doing a non-Propeller
AutoFDO build. This step builds a kernel that has the same optimization
level as AutoFDO, plus a metadata section that records basic block
information. This kernel image runs as fast as an AutoFDO optimized
kernel.
2) Install the kernel on test/production machines.
3) Run the load tests. The '-c' option in perf specifies the sample
event period. We suggest using a suitable prime number,
like 500009, for this purpose.
For Intel platforms:
$ perf record -e BR_INST_RETIRED.NEAR_TAKEN:k -a -N -b -c <count> \
-o <perf_file> -- <loadtest>
For AMD platforms:
The supported system are: Zen3 with BRS, or Zen4 with amd_lbr_v2
# To see if Zen3 support LBR:
$ cat proc/cpuinfo | grep " brs"
# To see if Zen4 support LBR:
$ cat proc/cpuinfo | grep amd_lbr_v2
# If the result is yes, then collect the profile using:
$ perf record --pfm-events RETIRED_TAKEN_BRANCH_INSTRUCTIONS:k -a \
-N -b -c <count> -o <perf_file> -- <loadtest>
4) (Optional) Download the raw perf file to the host machine.
5) Generate Propeller profile:
$ create_llvm_prof --binary=<vmlinux> --profile=<perf_file> \
--format=propeller --propeller_output_module_name \
--out=<propeller_profile_prefix>_cc_profile.txt \
--propeller_symorder=<propeller_profile_prefix>_ld_profile.txt
“create_llvm_prof” is the profile conversion tool, and a prebuilt
binary for linux can be found on
https://github.com/google/autofdo/releases/tag/v0.30.1 (can also build
from source).
"<propeller_profile_prefix>" can be something like
"/home/user/dir/any_string".
This command generates a pair of Propeller profiles:
"<propeller_profile_prefix>_cc_profile.txt" and
"<propeller_profile_prefix>_ld_profile.txt".
6) Rebuild the kernel using the AutoFDO and Propeller profile files.
CONFIG_AUTOFDO_CLANG=y
CONFIG_PROPELLER_CLANG=y
and
$ make LLVM=1 CLANG_AUTOFDO_PROFILE=<autofdo_profile> \
CLANG_PROPELLER_PROFILE_PREFIX=<propeller_profile_prefix>
Co-developed-by: Han Shen <shenhan@google.com>
Signed-off-by: Han Shen <shenhan@google.com>
Signed-off-by: Rong Xu <xur@google.com>
Suggested-by: Sriraman Tallam <tmsriram@google.com>
Suggested-by: Krzysztof Pszeniczny <kpszeniczny@google.com>
Suggested-by: Nick Desaulniers <ndesaulniers@google.com>
Suggested-by: Stephane Eranian <eranian@google.com>
Tested-by: Yonghong Song <yonghong.song@linux.dev>
Tested-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Kees Cook <kees@kernel.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-11-02 17:51:14 +00:00
|
|
|
include-$(CONFIG_PROPELLER_CLANG) += scripts/Makefile.propeller
|
2020-08-01 15:00:49 +00:00
|
|
|
include-$(CONFIG_GCC_PLUGINS) += scripts/Makefile.gcc-plugins
|
|
|
|
|
|
|
|
|
|
include $(addprefix $(srctree)/, $(include-y))
|
2014-04-14 09:27:10 +00:00
|
|
|
|
2020-08-01 15:00:50 +00:00
|
|
|
# scripts/Makefile.gcc-plugins is intentionally included last.
|
|
|
|
|
# Do not add $(call cc-option,...) below this line. When you build the kernel
|
|
|
|
|
# from the clean source tree, the GCC plugins do not exist at this point.
|
2014-04-14 09:27:10 +00:00
|
|
|
|
2021-07-03 14:42:57 +00:00
|
|
|
# Add user supplied CPPFLAGS, AFLAGS, CFLAGS and RUSTFLAGS as the last assignments
|
2019-08-20 17:09:41 +00:00
|
|
|
KBUILD_CPPFLAGS += $(KCPPFLAGS)
|
|
|
|
|
KBUILD_AFLAGS += $(KAFLAGS)
|
|
|
|
|
KBUILD_CFLAGS += $(KCFLAGS)
|
2021-07-03 14:42:57 +00:00
|
|
|
KBUILD_RUSTFLAGS += $(KRUSTFLAGS)
|
2007-10-15 20:03:58 +00:00
|
|
|
|
2020-09-22 23:21:40 +00:00
|
|
|
KBUILD_LDFLAGS_MODULE += --build-id=sha1
|
|
|
|
|
LDFLAGS_vmlinux += --build-id=sha1
|
2007-07-19 08:48:40 +00:00
|
|
|
|
2022-08-10 22:24:40 +00:00
|
|
|
KBUILD_LDFLAGS += -z noexecstack
|
|
|
|
|
ifeq ($(CONFIG_LD_IS_BFD),y)
|
|
|
|
|
KBUILD_LDFLAGS += $(call ld-option,--no-warn-rwx-segments)
|
|
|
|
|
endif
|
|
|
|
|
|
2009-03-04 19:59:07 +00:00
|
|
|
ifeq ($(CONFIG_STRIP_ASM_SYMS),y)
|
2022-09-29 18:12:23 +00:00
|
|
|
LDFLAGS_vmlinux += -X
|
2009-03-04 19:59:07 +00:00
|
|
|
endif
|
|
|
|
|
|
2019-08-01 01:18:42 +00:00
|
|
|
ifeq ($(CONFIG_RELR),y)
|
2023-04-11 20:09:44 +00:00
|
|
|
# ld.lld before 15 did not support -z pack-relative-relocs.
|
|
|
|
|
LDFLAGS_vmlinux += $(call ld-option,--pack-dyn-relocs=relr,-z pack-relative-relocs)
|
2019-08-01 01:18:42 +00:00
|
|
|
endif
|
|
|
|
|
|
2020-11-19 20:46:56 +00:00
|
|
|
# We never want expected sections to be placed heuristically by the
|
|
|
|
|
# linker. All sections should be explicitly named in the linker script.
|
|
|
|
|
ifdef CONFIG_LD_ORPHAN_WARN
|
2022-10-25 07:30:23 +00:00
|
|
|
LDFLAGS_vmlinux += --orphan-handling=$(CONFIG_LD_ORPHAN_WARN_LEVEL)
|
2020-11-19 20:46:56 +00:00
|
|
|
endif
|
|
|
|
|
|
kbuild: add infrastructure to build userspace programs
Kbuild supports the infrastructure to build host programs, but there
was no support to build userspace programs for the target architecture
(i.e. the same architecture as the kernel).
Sam Ravnborg worked on this in 2014 (https://lkml.org/lkml/2014/7/13/154),
but it was not merged. One problem at that time was, there was no good way
to know whether $(CC) can link standalone programs. In fact, pre-built
kernel.org toolchains [1] are often used for building the kernel, but they
do not provide libc.
Now, we can handle this cleanly because the compiler capability is
evaluated at the Kconfig time. If $(CC) cannot link standalone programs,
the relevant options are hidden by 'depends on CC_CAN_LINK'.
The implementation just mimics scripts/Makefile.host
The userspace programs are compiled with the same flags as the host
programs. In addition, it uses -m32 or -m64 if it is found in
$(KBUILD_CFLAGS).
This new syntax has two usecases.
- Sample programs
Several userspace programs under samples/ include UAPI headers
installed in usr/include. Most of them were previously built for
the host architecture just to use the 'hostprogs' syntax.
However, 'make headers' always works for the target architecture.
This caused the arch mismatch in cross-compiling. To fix this
distortion, sample code should be built for the target architecture.
- Bpfilter
net/bpfilter/Makefile compiles bpfilter_umh as the user mode helper,
and embeds it into the kernel. Currently, it overrides HOSTCC with
CC to use the 'hostprogs' syntax. This hack should go away.
[1]: https://mirrors.edge.kernel.org/pub/tools/crosstool/
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
2020-04-29 03:45:14 +00:00
|
|
|
# Align the bit size of userspace programs with the kernel
|
2020-06-30 15:06:25 +00:00
|
|
|
KBUILD_USERCFLAGS += $(filter -m32 -m64 --target=%, $(KBUILD_CFLAGS))
|
|
|
|
|
KBUILD_USERLDFLAGS += $(filter -m32 -m64 --target=%, $(KBUILD_CFLAGS))
|
kbuild: add infrastructure to build userspace programs
Kbuild supports the infrastructure to build host programs, but there
was no support to build userspace programs for the target architecture
(i.e. the same architecture as the kernel).
Sam Ravnborg worked on this in 2014 (https://lkml.org/lkml/2014/7/13/154),
but it was not merged. One problem at that time was, there was no good way
to know whether $(CC) can link standalone programs. In fact, pre-built
kernel.org toolchains [1] are often used for building the kernel, but they
do not provide libc.
Now, we can handle this cleanly because the compiler capability is
evaluated at the Kconfig time. If $(CC) cannot link standalone programs,
the relevant options are hidden by 'depends on CC_CAN_LINK'.
The implementation just mimics scripts/Makefile.host
The userspace programs are compiled with the same flags as the host
programs. In addition, it uses -m32 or -m64 if it is found in
$(KBUILD_CFLAGS).
This new syntax has two usecases.
- Sample programs
Several userspace programs under samples/ include UAPI headers
installed in usr/include. Most of them were previously built for
the host architecture just to use the 'hostprogs' syntax.
However, 'make headers' always works for the target architecture.
This caused the arch mismatch in cross-compiling. To fix this
distortion, sample code should be built for the target architecture.
- Bpfilter
net/bpfilter/Makefile compiles bpfilter_umh as the user mode helper,
and embeds it into the kernel. Currently, it overrides HOSTCC with
CC to use the 'hostprogs' syntax. This hack should go away.
[1]: https://mirrors.edge.kernel.org/pub/tools/crosstool/
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Acked-by: Sam Ravnborg <sam@ravnborg.org>
2020-04-29 03:45:14 +00:00
|
|
|
|
2019-11-09 12:12:16 +00:00
|
|
|
# make the checker run with the right architecture
|
|
|
|
|
CHECKFLAGS += --arch=$(ARCH)
|
|
|
|
|
|
2018-05-28 18:27:35 +00:00
|
|
|
# insure the checker run with the right endianness
|
|
|
|
|
CHECKFLAGS += $(if $(CONFIG_CPU_BIG_ENDIAN),-mbig-endian,-mlittle-endian)
|
|
|
|
|
|
2018-05-30 20:48:38 +00:00
|
|
|
# the checker needs the correct machine size
|
|
|
|
|
CHECKFLAGS += $(if $(CONFIG_64BIT),-m64,-m32)
|
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
# Default kernel image to build when no specific target is given.
|
2006-06-24 22:07:55 +00:00
|
|
|
# KBUILD_IMAGE may be overruled on the command line or
|
2005-04-16 22:20:36 +00:00
|
|
|
# set in the environment
|
|
|
|
|
# Also any assignments in arch/$(ARCH)/Makefile take precedence over
|
|
|
|
|
# this default value
|
|
|
|
|
export KBUILD_IMAGE ?= vmlinux
|
|
|
|
|
|
|
|
|
|
#
|
|
|
|
|
# INSTALL_PATH specifies where to place the updated kernel and system map
|
|
|
|
|
# images. Default is /boot, but you can set it to other values
|
|
|
|
|
export INSTALL_PATH ?= /boot
|
|
|
|
|
|
2013-12-01 23:56:28 +00:00
|
|
|
#
|
|
|
|
|
# INSTALL_DTBS_PATH specifies a prefix for relocations required by build roots.
|
|
|
|
|
# Like INSTALL_MOD_PATH, it isn't defined in the Makefile, but can be passed as
|
|
|
|
|
# an argument if needed. Otherwise it defaults to the kernel install path
|
|
|
|
|
#
|
|
|
|
|
export INSTALL_DTBS_PATH ?= $(INSTALL_PATH)/dtbs/$(KERNELRELEASE)
|
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
#
|
|
|
|
|
# INSTALL_MOD_PATH specifies a prefix to MODLIB for module directory
|
|
|
|
|
# relocations required by build roots. This is not defined in the
|
2006-06-24 22:07:55 +00:00
|
|
|
# makefile but the argument can be passed to make if needed.
|
2005-04-16 22:20:36 +00:00
|
|
|
#
|
|
|
|
|
|
2006-01-16 11:46:07 +00:00
|
|
|
MODLIB = $(INSTALL_MOD_PATH)/lib/modules/$(KERNELRELEASE)
|
2005-04-16 22:20:36 +00:00
|
|
|
export MODLIB
|
|
|
|
|
|
2019-01-15 07:19:00 +00:00
|
|
|
PHONY += prepare0
|
2012-10-19 01:23:15 +00:00
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
ifeq ($(KBUILD_EXTMOD),)
|
|
|
|
|
|
2022-09-24 18:19:10 +00:00
|
|
|
build-dir := .
|
|
|
|
|
clean-dirs := $(sort . Documentation \
|
2020-06-01 05:56:57 +00:00
|
|
|
$(patsubst %/,%,$(filter %/, $(core-) \
|
2020-06-01 05:56:58 +00:00
|
|
|
$(drivers-) $(libs-))))
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2022-09-24 18:19:10 +00:00
|
|
|
export ARCH_CORE := $(core-y)
|
|
|
|
|
export ARCH_LIB := $(filter %/, $(libs-y))
|
|
|
|
|
export ARCH_DRIVERS := $(drivers-y) $(drivers-m)
|
2020-06-01 05:56:59 +00:00
|
|
|
# Externally visible symbols (used by link-vmlinux.sh)
|
2022-09-24 18:19:10 +00:00
|
|
|
|
2022-09-24 18:19:14 +00:00
|
|
|
KBUILD_VMLINUX_OBJS := ./built-in.a
|
kbuild: link lib-y objects to vmlinux forcibly when CONFIG_MODULES=y
Kbuild supports not only obj-y but also lib-y to list objects linked to
vmlinux.
The difference between them is that all the objects from obj-y are
forcibly linked to vmlinux, whereas the objects from lib-y are linked
as needed; if there is no user of a lib-y object, it is not linked.
lib-y is intended to list utility functions that may be called from all
over the place (and may be unused at all), but it is a problem for
EXPORT_SYMBOL(). Even if there is no call-site in the vmlinux, we need
to keep exported symbols for the use from loadable modules.
Commit 7f2084fa55e6 ("[kbuild] handle exports in lib-y objects reliably")
worked around it by linking a dummy object, lib-ksyms.o, which contains
references to all the symbols exported from lib.a in that directory.
It uses the linker script command, EXTERN. Unfortunately, the meaning of
EXTERN of ld.lld is different from that of ld.bfd. Therefore, this does
not work with LD=ld.lld (CBL issue #515).
Anyway, the build rule of lib-ksyms.o is somewhat tricky. So, I want to
get rid of it.
At first, I was thinking of accumulating lib-y objects into obj-y
(or even replacing lib-y with obj-y entirely), but the lib-y syntax
is used beyond the ordinary use in lib/ and arch/*/lib/.
Examples:
- drivers/firmware/efi/libstub/Makefile builds lib.a, which is linked
into vmlinux in the own way (arm64), or linked to the decompressor
(arm, x86).
- arch/alpha/lib/Makefile builds lib.a which is linked not only to
vmlinux, but also to bootloaders in arch/alpha/boot/Makefile.
- arch/xtensa/boot/lib/Makefile builds lib.a for use from
arch/xtensa/boot/boot-redboot/Makefile.
One more thing, adding everything to obj-y would increase the vmlinux
size of allnoconfig (or tinyconfig).
For less impact, I tweaked the destination of lib.a at the top Makefile;
when CONFIG_MODULES=y, lib.a goes to KBUILD_VMLINUX_OBJS, which is
forcibly linked to vmlinux, otherwise lib.a goes to KBUILD_VMLINUX_LIBS
as before.
The size impact for normal usecases is quite small since at lease one
symbol in every lib-y object is eventually called by someone. In case
you are intrested, here are the figures.
x86_64_defconfig:
text data bss dec hex filename
19566602 5422072 1589328 26578002 1958c52 vmlinux.before
19566932 5422104 1589328 26578364 1958dbc vmlinux.after
The case with the biggest impact is allnoconfig + CONFIG_MODULES=y.
ARCH=x86 allnoconfig + CONFIG_MODULES=y:
text data bss dec hex filename
1175162 254740 1220608 2650510 28718e vmlinux.before
1177974 254836 1220608 2653418 287cea vmlinux.after
Hopefully this is still not a big deal. The per-file trimming with the
static library is not so effective after all.
If fine-grained optimization is desired, some architectures support
CONFIG_LD_DEAD_CODE_DATA_ELIMINATION, which trims dead code per-symbol
basis. When LTO is supported in mainline, even better optimization will
be possible.
Link: https://github.com/ClangBuiltLinux/linux/issues/515
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reported-by: kbuild test robot <lkp@intel.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
2020-03-11 22:37:25 +00:00
|
|
|
ifdef CONFIG_MODULES
|
2020-06-01 05:56:59 +00:00
|
|
|
KBUILD_VMLINUX_OBJS += $(patsubst %/, %/lib.a, $(filter %/, $(libs-y)))
|
|
|
|
|
KBUILD_VMLINUX_LIBS := $(filter-out %/, $(libs-y))
|
kbuild: link lib-y objects to vmlinux forcibly when CONFIG_MODULES=y
Kbuild supports not only obj-y but also lib-y to list objects linked to
vmlinux.
The difference between them is that all the objects from obj-y are
forcibly linked to vmlinux, whereas the objects from lib-y are linked
as needed; if there is no user of a lib-y object, it is not linked.
lib-y is intended to list utility functions that may be called from all
over the place (and may be unused at all), but it is a problem for
EXPORT_SYMBOL(). Even if there is no call-site in the vmlinux, we need
to keep exported symbols for the use from loadable modules.
Commit 7f2084fa55e6 ("[kbuild] handle exports in lib-y objects reliably")
worked around it by linking a dummy object, lib-ksyms.o, which contains
references to all the symbols exported from lib.a in that directory.
It uses the linker script command, EXTERN. Unfortunately, the meaning of
EXTERN of ld.lld is different from that of ld.bfd. Therefore, this does
not work with LD=ld.lld (CBL issue #515).
Anyway, the build rule of lib-ksyms.o is somewhat tricky. So, I want to
get rid of it.
At first, I was thinking of accumulating lib-y objects into obj-y
(or even replacing lib-y with obj-y entirely), but the lib-y syntax
is used beyond the ordinary use in lib/ and arch/*/lib/.
Examples:
- drivers/firmware/efi/libstub/Makefile builds lib.a, which is linked
into vmlinux in the own way (arm64), or linked to the decompressor
(arm, x86).
- arch/alpha/lib/Makefile builds lib.a which is linked not only to
vmlinux, but also to bootloaders in arch/alpha/boot/Makefile.
- arch/xtensa/boot/lib/Makefile builds lib.a for use from
arch/xtensa/boot/boot-redboot/Makefile.
One more thing, adding everything to obj-y would increase the vmlinux
size of allnoconfig (or tinyconfig).
For less impact, I tweaked the destination of lib.a at the top Makefile;
when CONFIG_MODULES=y, lib.a goes to KBUILD_VMLINUX_OBJS, which is
forcibly linked to vmlinux, otherwise lib.a goes to KBUILD_VMLINUX_LIBS
as before.
The size impact for normal usecases is quite small since at lease one
symbol in every lib-y object is eventually called by someone. In case
you are intrested, here are the figures.
x86_64_defconfig:
text data bss dec hex filename
19566602 5422072 1589328 26578002 1958c52 vmlinux.before
19566932 5422104 1589328 26578364 1958dbc vmlinux.after
The case with the biggest impact is allnoconfig + CONFIG_MODULES=y.
ARCH=x86 allnoconfig + CONFIG_MODULES=y:
text data bss dec hex filename
1175162 254740 1220608 2650510 28718e vmlinux.before
1177974 254836 1220608 2653418 287cea vmlinux.after
Hopefully this is still not a big deal. The per-file trimming with the
static library is not so effective after all.
If fine-grained optimization is desired, some architectures support
CONFIG_LD_DEAD_CODE_DATA_ELIMINATION, which trims dead code per-symbol
basis. When LTO is supported in mainline, even better optimization will
be possible.
Link: https://github.com/ClangBuiltLinux/linux/issues/515
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reported-by: kbuild test robot <lkp@intel.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
2020-03-11 22:37:25 +00:00
|
|
|
else
|
2020-06-01 05:56:59 +00:00
|
|
|
KBUILD_VMLINUX_LIBS := $(patsubst %/,%/lib.a, $(libs-y))
|
kbuild: link lib-y objects to vmlinux forcibly when CONFIG_MODULES=y
Kbuild supports not only obj-y but also lib-y to list objects linked to
vmlinux.
The difference between them is that all the objects from obj-y are
forcibly linked to vmlinux, whereas the objects from lib-y are linked
as needed; if there is no user of a lib-y object, it is not linked.
lib-y is intended to list utility functions that may be called from all
over the place (and may be unused at all), but it is a problem for
EXPORT_SYMBOL(). Even if there is no call-site in the vmlinux, we need
to keep exported symbols for the use from loadable modules.
Commit 7f2084fa55e6 ("[kbuild] handle exports in lib-y objects reliably")
worked around it by linking a dummy object, lib-ksyms.o, which contains
references to all the symbols exported from lib.a in that directory.
It uses the linker script command, EXTERN. Unfortunately, the meaning of
EXTERN of ld.lld is different from that of ld.bfd. Therefore, this does
not work with LD=ld.lld (CBL issue #515).
Anyway, the build rule of lib-ksyms.o is somewhat tricky. So, I want to
get rid of it.
At first, I was thinking of accumulating lib-y objects into obj-y
(or even replacing lib-y with obj-y entirely), but the lib-y syntax
is used beyond the ordinary use in lib/ and arch/*/lib/.
Examples:
- drivers/firmware/efi/libstub/Makefile builds lib.a, which is linked
into vmlinux in the own way (arm64), or linked to the decompressor
(arm, x86).
- arch/alpha/lib/Makefile builds lib.a which is linked not only to
vmlinux, but also to bootloaders in arch/alpha/boot/Makefile.
- arch/xtensa/boot/lib/Makefile builds lib.a for use from
arch/xtensa/boot/boot-redboot/Makefile.
One more thing, adding everything to obj-y would increase the vmlinux
size of allnoconfig (or tinyconfig).
For less impact, I tweaked the destination of lib.a at the top Makefile;
when CONFIG_MODULES=y, lib.a goes to KBUILD_VMLINUX_OBJS, which is
forcibly linked to vmlinux, otherwise lib.a goes to KBUILD_VMLINUX_LIBS
as before.
The size impact for normal usecases is quite small since at lease one
symbol in every lib-y object is eventually called by someone. In case
you are intrested, here are the figures.
x86_64_defconfig:
text data bss dec hex filename
19566602 5422072 1589328 26578002 1958c52 vmlinux.before
19566932 5422104 1589328 26578364 1958dbc vmlinux.after
The case with the biggest impact is allnoconfig + CONFIG_MODULES=y.
ARCH=x86 allnoconfig + CONFIG_MODULES=y:
text data bss dec hex filename
1175162 254740 1220608 2650510 28718e vmlinux.before
1177974 254836 1220608 2653418 287cea vmlinux.after
Hopefully this is still not a big deal. The per-file trimming with the
static library is not so effective after all.
If fine-grained optimization is desired, some architectures support
CONFIG_LD_DEAD_CODE_DATA_ELIMINATION, which trims dead code per-symbol
basis. When LTO is supported in mainline, even better optimization will
be possible.
Link: https://github.com/ClangBuiltLinux/linux/issues/515
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reported-by: kbuild test robot <lkp@intel.com>
Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
2020-03-11 22:37:25 +00:00
|
|
|
endif
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2022-09-24 18:19:14 +00:00
|
|
|
export KBUILD_VMLINUX_LIBS
|
2012-05-05 08:18:40 +00:00
|
|
|
export KBUILD_LDS := arch/$(SRCARCH)/kernel/vmlinux.lds
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2016-04-22 19:25:00 +00:00
|
|
|
ifdef CONFIG_TRIM_UNUSED_KSYMS
|
2018-03-16 07:37:13 +00:00
|
|
|
# For the kernel to actually contain only the needed exported symbols,
|
|
|
|
|
# we have to build modules as well to determine what those symbols are.
|
2020-05-31 10:11:39 +00:00
|
|
|
KBUILD_MODULES := 1
|
2018-03-16 07:37:13 +00:00
|
|
|
endif
|
|
|
|
|
|
2022-09-24 18:19:14 +00:00
|
|
|
# '$(AR) mPi' needs 'T' to workaround the bug of llvm-ar <= 14
|
|
|
|
|
quiet_cmd_ar_vmlinux.a = AR $@
|
|
|
|
|
cmd_ar_vmlinux.a = \
|
|
|
|
|
rm -f $@; \
|
|
|
|
|
$(AR) cDPrST $@ $(KBUILD_VMLINUX_OBJS); \
|
2022-10-27 16:28:39 +00:00
|
|
|
$(AR) mPiT $$($(AR) t $@ | sed -n 1p) $@ $$($(AR) t $@ | grep -F -f $(srctree)/scripts/head-object-list.txt)
|
2016-08-24 12:29:21 +00:00
|
|
|
|
2022-09-24 18:19:14 +00:00
|
|
|
targets += vmlinux.a
|
kbuild: implement CONFIG_TRIM_UNUSED_KSYMS without recursion
When CONFIG_TRIM_UNUSED_KSYMS is enabled, Kbuild recursively traverses
the directory tree to determine which EXPORT_SYMBOL to trim. If an
EXPORT_SYMBOL turns out to be unused by anyone, Kbuild begins the
second traverse, where some source files are recompiled with their
EXPORT_SYMBOL() tuned into a no-op.
Linus stated negative opinions about this slowness in commits:
- 5cf0fd591f2e ("Kbuild: disable TRIM_UNUSED_KSYMS option")
- a555bdd0c58c ("Kbuild: enable TRIM_UNUSED_KSYMS again, with some guarding")
We can do this better now. The final data structures of EXPORT_SYMBOL
are generated by the modpost stage, so modpost can selectively emit
KSYMTAB entries that are really used by modules.
Commit f73edc8951b2 ("kbuild: unify two modpost invocations") is another
ground-work to do this in a one-pass algorithm. With the list of modules,
modpost sets sym->used if it is used by a module. modpost emits KSYMTAB
only for symbols with sym->used==true.
BTW, Nicolas explained why the trimming was implemented with recursion:
https://lore.kernel.org/all/2o2rpn97-79nq-p7s2-nq5-8p83391473r@syhkavp.arg/
Actually, we never achieved that level of optimization where the chain
reaction of trimming comes into play because:
- CONFIG_LTO_CLANG cannot remove any unused symbols
- CONFIG_LD_DEAD_CODE_DATA_ELIMINATION is enabled only for vmlinux,
but not modules
If deeper trimming is required, we need to revisit this, but I guess
that is unlikely to happen.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2023-06-11 15:50:57 +00:00
|
|
|
vmlinux.a: $(KBUILD_VMLINUX_OBJS) scripts/head-object-list.txt FORCE
|
2022-09-24 18:19:14 +00:00
|
|
|
$(call if_changed,ar_vmlinux.a)
|
2016-04-22 19:25:00 +00:00
|
|
|
|
2022-09-28 06:39:40 +00:00
|
|
|
PHONY += vmlinux_o
|
|
|
|
|
vmlinux_o: vmlinux.a $(KBUILD_VMLINUX_LIBS)
|
2022-09-24 18:19:12 +00:00
|
|
|
$(Q)$(MAKE) -f $(srctree)/scripts/Makefile.vmlinux_o
|
2007-07-17 08:54:06 +00:00
|
|
|
|
2022-09-28 06:39:40 +00:00
|
|
|
vmlinux.o modules.builtin.modinfo modules.builtin: vmlinux_o
|
|
|
|
|
@:
|
|
|
|
|
|
2022-09-28 06:39:41 +00:00
|
|
|
PHONY += vmlinux
|
kbuild: export top-level LDFLAGS_vmlinux only to scripts/Makefile.vmlinux
Nathan Chancellor reports that $(NM) emits an error message when
GNU Make 4.4 is used to build the ARM zImage.
$ make-4.4 ARCH=arm CROSS_COMPILE=arm-linux-gnueabi- O=build defconfig zImage
[snip]
LD vmlinux
NM System.map
SORTTAB vmlinux
OBJCOPY arch/arm/boot/Image
Kernel: arch/arm/boot/Image is ready
arm-linux-gnueabi-nm: 'arch/arm/boot/compressed/../../../../vmlinux': No such file
/bin/sh: 1: arithmetic expression: expecting primary: " "
LDS arch/arm/boot/compressed/vmlinux.lds
AS arch/arm/boot/compressed/head.o
GZIP arch/arm/boot/compressed/piggy_data
AS arch/arm/boot/compressed/piggy.o
CC arch/arm/boot/compressed/misc.o
This occurs since GNU Make commit 98da874c4303 ("[SV 10593] Export
variables to $(shell ...) commands"), and the O= option is needed to
reproduce it. The generated zImage is correct despite the error message.
As the commit description of 98da874c4303 [1] says, exported variables
are passed down to $(shell ) functions, which means exported recursive
variables might be expanded earlier than before, in the parse stage.
The following test code demonstrates the change for GNU Make 4.4.
[Test Makefile]
$(shell echo hello > foo)
export foo = $(shell cat bar/../foo)
$(shell mkdir bar)
all:
@echo $(foo)
[GNU Make 4.3]
$ rm -rf bar; make-4.3
hello
[GNU Make 4.4]
$ rm -rf bar; make-4.4
cat: bar/../foo: No such file or directory
hello
The 'foo' is a resursively expanded (i.e. lazily expanded) variable.
GNU Make 4.3 expands 'foo' just before running the recipe '@echo $(foo)',
at this point, the directory 'bar' exists.
GNU Make 4.4 expands 'foo' to evaluate $(shell mkdir bar) because it is
exported. At this point, the directory 'bar' does not exit yet. The cat
command cannot resolve the bar/../foo path, hence the error message.
Let's get back to the kernel Makefile.
In arch/arm/boot/compressed/Makefile, KBSS_SZ is referenced by
LDFLAGS_vmlinux, which is recursive and also exported by the top
Makefile.
GNU Make 4.3 expands KBSS_SZ just before running the recipes, so no
error message.
GNU Make 4.4 expands KBSS_SZ in the parse stage, where the directory
arm/arm/boot/compressed does not exit yet. When compiled with O=,
the output directory is created by $(shell mkdir -p $(obj-dirs))
in scripts/Makefile.build.
There are two ways to fix this particular issue:
- change "$(obj)/../../../../vmlinux" in KBSS_SZ to "vmlinux"
- unexport LDFLAGS_vmlinux
This commit takes the latter course because it is what I originally
intended.
Commit 3ec8a5b33dea ("kbuild: do not export LDFLAGS_vmlinux")
unexported LDFLAGS_vmlinux.
Commit 5d4aeffbf709 ("kbuild: rebuild .vmlinux.export.o when its
prerequisite is updated") accidentally exported it again.
We can clean up arch/arm/boot/compressed/Makefile later.
[1]: https://git.savannah.gnu.org/cgit/make.git/commit/?id=98da874c43035a490cdca81331724f233a3d0c9a
Link: https://lore.kernel.org/all/Y7i8+EjwdnhHtlrr@dev-arch.thelio-3990X/
Fixes: 5d4aeffbf709 ("kbuild: rebuild .vmlinux.export.o when its prerequisite is updated")
Reported-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
Tested-by: Nathan Chancellor <nathan@kernel.org>
2023-01-08 19:23:17 +00:00
|
|
|
# LDFLAGS_vmlinux in the top Makefile defines linker flags for the top vmlinux,
|
|
|
|
|
# not for decompressors. LDFLAGS_vmlinux in arch/*/boot/compressed/Makefile is
|
|
|
|
|
# unrelated; the decompressors just happen to have the same base name,
|
|
|
|
|
# arch/*/boot/compressed/vmlinux.
|
|
|
|
|
# Export LDFLAGS_vmlinux only to scripts/Makefile.vmlinux.
|
|
|
|
|
#
|
|
|
|
|
# _LDFLAGS_vmlinux is a workaround for the 'private export' bug:
|
|
|
|
|
# https://savannah.gnu.org/bugs/?61463
|
|
|
|
|
# For Make > 4.4, the following simple code will work:
|
|
|
|
|
# vmlinux: private export LDFLAGS_vmlinux := $(LDFLAGS_vmlinux)
|
|
|
|
|
vmlinux: private _LDFLAGS_vmlinux := $(LDFLAGS_vmlinux)
|
|
|
|
|
vmlinux: export LDFLAGS_vmlinux = $(_LDFLAGS_vmlinux)
|
2022-09-28 06:39:41 +00:00
|
|
|
vmlinux: vmlinux.o $(KBUILD_LDS) modpost
|
|
|
|
|
$(Q)$(MAKE) -f $(srctree)/scripts/Makefile.vmlinux
|
kbuild: let fixdep directly write to .*.cmd files
Currently, fixdep writes dependencies to .*.tmp, which is renamed to
.*.cmd after everything succeeds. This is a very safe way to avoid
corrupted .*.cmd files. The if_changed_dep has carried this safety
mechanism since it was added in 2002.
If fixdep fails for some reasons or a user terminates the build while
fixdep is running, the incomplete output from the fixdep could be
troublesome.
This is my insight about some bad scenarios:
[1] If the compiler succeeds to generate *.o file, but fixdep fails
to write necessary dependencies to .*.cmd file, Make will miss
to rebuild the object when headers or CONFIG options are changed.
In this case, fixdep should not generate .*.cmd file at all so
that 'arg-check' will surely trigger the rebuild of the object.
[2] A partially constructed .*.cmd file may not be a syntactically
correct makefile. The next time Make runs, it would include it,
then fail to parse it. Once this happens, 'make clean' is be the
only way to fix it.
In fact, [1] is no longer a problem since commit 9c2af1c7377a ("kbuild:
add .DELETE_ON_ERROR special target"). Make deletes a target file on
any failure in its recipe. Because fixdep is a part of the recipe of
*.o target, if it fails, the *.o is deleted anyway. However, I am a
bit worried about the slight possibility of [2].
So, here is a solution. Let fixdep directly write to a .*.cmd file,
but allow makefiles to include it only when its corresponding target
exists.
This effectively reverts commit 2982c953570b ("kbuild: remove redundant
$(wildcard ...) for cmd_files calculation"), and commit 00d78ab2ba75
("kbuild: remove dead code in cmd_files calculation in top Makefile")
because now we must check the presence of targets.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-11-30 01:05:22 +00:00
|
|
|
|
2014-04-28 07:26:18 +00:00
|
|
|
# The actual objects are generated when descending,
|
2005-04-16 22:20:36 +00:00
|
|
|
# make sure no implicit rule kicks in
|
2022-09-24 18:19:12 +00:00
|
|
|
$(sort $(KBUILD_LDS) $(KBUILD_VMLINUX_OBJS) $(KBUILD_VMLINUX_LIBS)): . ;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2023-01-27 16:19:42 +00:00
|
|
|
ifeq ($(origin KERNELRELEASE),file)
|
2023-01-22 14:14:25 +00:00
|
|
|
filechk_kernel.release = $(srctree)/scripts/setlocalversion $(srctree)
|
2023-01-27 16:19:42 +00:00
|
|
|
else
|
|
|
|
|
filechk_kernel.release = echo $(KERNELRELEASE)
|
|
|
|
|
endif
|
2013-07-11 13:34:51 +00:00
|
|
|
|
2013-06-28 09:27:31 +00:00
|
|
|
# Store (new) KERNELRELEASE string in include/config/kernel.release
|
2019-04-07 10:03:18 +00:00
|
|
|
include/config/kernel.release: FORCE
|
2013-07-11 13:34:51 +00:00
|
|
|
$(call filechk,kernel.release)
|
2006-01-09 20:20:34 +00:00
|
|
|
|
2018-03-16 07:37:11 +00:00
|
|
|
# Additional helpers built in scripts/
|
|
|
|
|
# Carefully list dependencies so we do not try to build scripts twice
|
|
|
|
|
# in parallel
|
|
|
|
|
PHONY += scripts
|
2018-11-29 03:13:24 +00:00
|
|
|
scripts: scripts_basic scripts_dtc
|
2018-03-16 07:37:11 +00:00
|
|
|
$(Q)$(MAKE) $(build)=$(@)
|
2006-01-09 20:20:34 +00:00
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
# Things we need to do before we recursively start building the kernel
|
2005-09-11 20:30:22 +00:00
|
|
|
# or the modules are listed in "prepare".
|
|
|
|
|
# A multi level approach is used. prepareN is processed before prepareN-1.
|
|
|
|
|
# archprepare is used in arch Makefiles and when processed asm symlink,
|
|
|
|
|
# version.h and scripts_basic is processed / created.
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2019-08-22 04:46:12 +00:00
|
|
|
PHONY += prepare archprepare
|
2005-09-11 20:30:22 +00:00
|
|
|
|
2019-08-22 04:46:13 +00:00
|
|
|
archprepare: outputmakefile archheaders archscripts scripts include/config/kernel.release \
|
kbuild: implement CONFIG_TRIM_UNUSED_KSYMS without recursion
When CONFIG_TRIM_UNUSED_KSYMS is enabled, Kbuild recursively traverses
the directory tree to determine which EXPORT_SYMBOL to trim. If an
EXPORT_SYMBOL turns out to be unused by anyone, Kbuild begins the
second traverse, where some source files are recompiled with their
EXPORT_SYMBOL() tuned into a no-op.
Linus stated negative opinions about this slowness in commits:
- 5cf0fd591f2e ("Kbuild: disable TRIM_UNUSED_KSYMS option")
- a555bdd0c58c ("Kbuild: enable TRIM_UNUSED_KSYMS again, with some guarding")
We can do this better now. The final data structures of EXPORT_SYMBOL
are generated by the modpost stage, so modpost can selectively emit
KSYMTAB entries that are really used by modules.
Commit f73edc8951b2 ("kbuild: unify two modpost invocations") is another
ground-work to do this in a one-pass algorithm. With the list of modules,
modpost sets sym->used if it is used by a module. modpost emits KSYMTAB
only for symbols with sym->used==true.
BTW, Nicolas explained why the trimming was implemented with recursion:
https://lore.kernel.org/all/2o2rpn97-79nq-p7s2-nq5-8p83391473r@syhkavp.arg/
Actually, we never achieved that level of optimization where the chain
reaction of trimming comes into play because:
- CONFIG_LTO_CLANG cannot remove any unused symbols
- CONFIG_LD_DEAD_CODE_DATA_ELIMINATION is enabled only for vmlinux,
but not modules
If deeper trimming is required, we need to revisit this, but I guess
that is unlikely to happen.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2023-06-11 15:50:57 +00:00
|
|
|
asm-generic $(version_h) include/generated/utsrelease.h \
|
2024-09-17 14:16:39 +00:00
|
|
|
include/generated/compile.h include/generated/autoconf.h \
|
|
|
|
|
include/generated/rustc_cfg remove-stale-files
|
2005-09-11 20:30:22 +00:00
|
|
|
|
2018-11-29 02:58:50 +00:00
|
|
|
prepare0: archprepare
|
2018-11-29 03:13:24 +00:00
|
|
|
$(Q)$(MAKE) $(build)=scripts/mod
|
2022-08-20 09:15:28 +00:00
|
|
|
$(Q)$(MAKE) $(build)=. prepare
|
2005-09-09 17:28:28 +00:00
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
# All the preparing..
|
kbuild: remove libelf checks from top Makefile
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: Masahiro Yamada <masahiroy@kernel.org>
Acked-by: Andrii Nakryiko <andrii@kernel.org>
2021-05-12 06:52:01 +00:00
|
|
|
prepare: prepare0
|
2021-07-03 14:42:57 +00:00
|
|
|
ifdef CONFIG_RUST
|
kbuild: mark `rustc` (and others) invocations as recursive
`rustc` (like Cargo) may take advantage of the jobserver at any time
(e.g. for backend parallelism, or eventually frontend too). In the kernel,
we call `rustc` with `-Ccodegen-units=1` (and `-Zthreads` is 1 so far),
so we do not expect parallelism. However, in the upcoming Rust 1.76.0, a
warning is emitted by `rustc` [1] when it cannot connect to the jobserver
it was passed (in many cases, but not all: compiling and `--print sysroot`
do, but `--version` does not). And given GNU Make always passes
the jobserver in the environment variable (even when a line is deemed
non-recursive), `rustc` will end up complaining about it (in particular
in Make 4.3 where there is only the simple pipe jobserver style).
One solution is to remove the jobserver from `MAKEFLAGS`. However, we
can mark the lines with calls to `rustc` (and Cargo) as recursive, which
looks simpler. This is being documented as a recommendation in `rustc`
[2] and allows us to be ready for the time we may use parallelism inside
`rustc` (potentially now, if a user passes `-Zthreads`). Thus do so.
Similarly, do the same for `rustdoc` and `cargo` calls.
Finally, there is one case that the solution does not cover, which is the
`$(shell ...)` call we have. Thus, for that one, set an empty `MAKEFLAGS`
environment variable.
Link: https://github.com/rust-lang/rust/issues/120515 [1]
Acked-by: Masahiro Yamada <masahiroy@kernel.org>
Link: https://github.com/rust-lang/rust/pull/121564 [2]
Link: https://lore.kernel.org/r/20240217002638.57373-1-ojeda@kernel.org
[ Reworded to add link to PR documenting the recommendation. ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-02-17 00:26:37 +00:00
|
|
|
+$(Q)$(CONFIG_SHELL) $(srctree)/scripts/rust_is_available.sh
|
2021-07-03 14:42:57 +00:00
|
|
|
$(Q)$(MAKE) $(build)=rust
|
|
|
|
|
endif
|
2016-02-29 04:22:42 +00:00
|
|
|
|
2021-04-25 07:07:12 +00:00
|
|
|
PHONY += remove-stale-files
|
|
|
|
|
remove-stale-files:
|
|
|
|
|
$(Q)$(srctree)/scripts/remove-stale-files
|
|
|
|
|
|
2017-10-04 03:56:06 +00:00
|
|
|
# Support for using generic headers in asm-generic
|
2024-04-26 13:19:48 +00:00
|
|
|
asm-generic := -f $(srctree)/scripts/Makefile.asm-headers obj
|
2018-12-05 11:28:04 +00:00
|
|
|
|
2017-10-04 03:56:06 +00:00
|
|
|
PHONY += asm-generic uapi-asm-generic
|
|
|
|
|
asm-generic: uapi-asm-generic
|
2019-03-17 02:01:09 +00:00
|
|
|
$(Q)$(MAKE) $(asm-generic)=arch/$(SRCARCH)/include/generated/asm \
|
|
|
|
|
generic=include/asm-generic
|
2017-10-04 03:56:06 +00:00
|
|
|
uapi-asm-generic:
|
2019-03-17 02:01:09 +00:00
|
|
|
$(Q)$(MAKE) $(asm-generic)=arch/$(SRCARCH)/include/generated/uapi/asm \
|
|
|
|
|
generic=include/uapi/asm-generic
|
2017-10-04 03:56:06 +00:00
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
# Generate some files
|
|
|
|
|
# ---------------------------------------------------------------------------
|
|
|
|
|
|
|
|
|
|
# KERNELRELEASE can change from a few different places, meaning version.h
|
|
|
|
|
# needs to be updated, so this check is forced on all builds
|
|
|
|
|
|
|
|
|
|
uts_len := 64
|
2006-07-03 21:30:54 +00:00
|
|
|
define filechk_utsrelease.h
|
|
|
|
|
if [ `echo -n "$(KERNELRELEASE)" | wc -c ` -gt $(uts_len) ]; then \
|
|
|
|
|
echo '"$(KERNELRELEASE)" exceeds $(uts_len) characters' >&2; \
|
|
|
|
|
exit 1; \
|
|
|
|
|
fi; \
|
2018-12-31 08:24:09 +00:00
|
|
|
echo \#define UTS_RELEASE \"$(KERNELRELEASE)\"
|
2006-07-03 21:30:54 +00:00
|
|
|
endef
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
|
define filechk_version.h
|
2021-02-06 03:50:32 +00:00
|
|
|
if [ $(SUBLEVEL) -gt 255 ]; then \
|
|
|
|
|
echo \#define LINUX_VERSION_CODE $(shell \
|
2021-02-27 14:20:23 +00:00
|
|
|
expr $(VERSION) \* 65536 + $(PATCHLEVEL) \* 256 + 255); \
|
2021-02-06 03:50:32 +00:00
|
|
|
else \
|
|
|
|
|
echo \#define LINUX_VERSION_CODE $(shell \
|
2021-02-27 14:20:23 +00:00
|
|
|
expr $(VERSION) \* 65536 + $(PATCHLEVEL) \* 256 + $(SUBLEVEL)); \
|
2021-02-06 03:50:32 +00:00
|
|
|
fi; \
|
|
|
|
|
echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + \
|
2021-02-12 16:29:24 +00:00
|
|
|
((c) > 255 ? 255 : (c)))'; \
|
|
|
|
|
echo \#define LINUX_VERSION_MAJOR $(VERSION); \
|
|
|
|
|
echo \#define LINUX_VERSION_PATCHLEVEL $(PATCHLEVEL); \
|
|
|
|
|
echo \#define LINUX_VERSION_SUBLEVEL $(SUBLEVEL)
|
2005-04-16 22:20:36 +00:00
|
|
|
endef
|
|
|
|
|
|
2024-04-27 15:32:53 +00:00
|
|
|
$(version_h): private PATCHLEVEL := $(or $(PATCHLEVEL), 0)
|
|
|
|
|
$(version_h): private SUBLEVEL := $(or $(SUBLEVEL), 0)
|
2018-07-25 05:16:11 +00:00
|
|
|
$(version_h): FORCE
|
2005-04-16 22:20:36 +00:00
|
|
|
$(call filechk,version.h)
|
|
|
|
|
|
2009-10-17 22:52:28 +00:00
|
|
|
include/generated/utsrelease.h: include/config/kernel.release FORCE
|
2006-07-03 21:30:54 +00:00
|
|
|
$(call filechk,utsrelease.h)
|
|
|
|
|
|
2022-08-28 02:39:54 +00:00
|
|
|
filechk_compile.h = $(srctree)/scripts/mkcompile_h \
|
|
|
|
|
"$(UTS_MACHINE)" "$(CONFIG_CC_VERSION_TEXT)" "$(LD)"
|
|
|
|
|
|
|
|
|
|
include/generated/compile.h: FORCE
|
|
|
|
|
$(call filechk,compile.h)
|
|
|
|
|
|
2008-12-16 11:33:43 +00:00
|
|
|
PHONY += headerdep
|
|
|
|
|
headerdep:
|
2011-04-26 21:17:11 +00:00
|
|
|
$(Q)find $(srctree)/include/ -name '*.h' | xargs --max-args 1 \
|
|
|
|
|
$(srctree)/scripts/headerdep.pl -I$(srctree)/include
|
2008-12-16 11:33:43 +00:00
|
|
|
|
2006-06-18 10:58:39 +00:00
|
|
|
# ---------------------------------------------------------------------------
|
|
|
|
|
# Kernel headers
|
|
|
|
|
|
2008-06-05 14:43:46 +00:00
|
|
|
#Default location for installed headers
|
|
|
|
|
export INSTALL_HDR_PATH = $(objtree)/usr
|
2006-09-24 21:16:03 +00:00
|
|
|
|
kbuild: add 'headers' target to build up uapi headers in usr/include
In Linux build system, build targets and installation targets are
separated.
Examples are:
- 'make vmlinux' -> 'make install'
- 'make modules' -> 'make modules_install'
- 'make dtbs' -> 'make dtbs_install'
- 'make vdso' -> 'make vdso_install'
The intention is to run the build targets under the normal privilege,
then the installation targets under the root privilege since we need
the write permission to the system directories.
We have 'make headers_install' but the corresponding 'make headers'
stage does not exist. The purpose of headers_install is to provide
the kernel interface to C library. So, nobody would try to install
headers to /usr/include directly.
If 'sudo make INSTALL_HDR_PATH=/usr/include headers_install' were run,
some build artifacts in the kernel tree would be owned by root because
some of uapi headers are generated by 'uapi-asm-generic', 'archheaders'
targets.
Anyway, I believe it makes sense to split the header installation into
two stages.
[1] 'make headers'
Process headers in uapi directories by scripts/headers_install.sh
and copy them to usr/include
[2] 'make headers_install'
Copy '*.h' verbatim from usr/include to $(INSTALL_HDR_PATH)/include
For the backward compatibility, 'headers_install' depends on 'headers'.
Some samples expect uapi headers in usr/include. So, the 'headers'
target is useful to build up them in the fixed location usr/include
irrespective of INSTALL_HDR_PATH.
Another benefit is to stop polluting the final destination with the
time-stamp files '.install' and '.check'. Maybe you can see them in
your toolchains.
Lastly, my main motivation is to prepare for compile-testing uapi
headers. To build something, we have to save an object and .*.cmd
somewhere. The usr/include/ will be the work directory for that.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-06-04 10:14:02 +00:00
|
|
|
quiet_cmd_headers_install = INSTALL $(INSTALL_HDR_PATH)/include
|
|
|
|
|
cmd_headers_install = \
|
|
|
|
|
mkdir -p $(INSTALL_HDR_PATH); \
|
|
|
|
|
rsync -mrl --include='*/' --include='*\.h' --exclude='*' \
|
|
|
|
|
usr/include $(INSTALL_HDR_PATH)
|
2008-06-05 14:43:46 +00:00
|
|
|
|
2006-06-18 10:58:39 +00:00
|
|
|
PHONY += headers_install
|
kbuild: add 'headers' target to build up uapi headers in usr/include
In Linux build system, build targets and installation targets are
separated.
Examples are:
- 'make vmlinux' -> 'make install'
- 'make modules' -> 'make modules_install'
- 'make dtbs' -> 'make dtbs_install'
- 'make vdso' -> 'make vdso_install'
The intention is to run the build targets under the normal privilege,
then the installation targets under the root privilege since we need
the write permission to the system directories.
We have 'make headers_install' but the corresponding 'make headers'
stage does not exist. The purpose of headers_install is to provide
the kernel interface to C library. So, nobody would try to install
headers to /usr/include directly.
If 'sudo make INSTALL_HDR_PATH=/usr/include headers_install' were run,
some build artifacts in the kernel tree would be owned by root because
some of uapi headers are generated by 'uapi-asm-generic', 'archheaders'
targets.
Anyway, I believe it makes sense to split the header installation into
two stages.
[1] 'make headers'
Process headers in uapi directories by scripts/headers_install.sh
and copy them to usr/include
[2] 'make headers_install'
Copy '*.h' verbatim from usr/include to $(INSTALL_HDR_PATH)/include
For the backward compatibility, 'headers_install' depends on 'headers'.
Some samples expect uapi headers in usr/include. So, the 'headers'
target is useful to build up them in the fixed location usr/include
irrespective of INSTALL_HDR_PATH.
Another benefit is to stop polluting the final destination with the
time-stamp files '.install' and '.check'. Maybe you can see them in
your toolchains.
Lastly, my main motivation is to prepare for compile-testing uapi
headers. To build something, we have to save an object and .*.cmd
somewhere. The usr/include/ will be the work directory for that.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-06-04 10:14:02 +00:00
|
|
|
headers_install: headers
|
|
|
|
|
$(call cmd,headers_install)
|
2012-05-08 18:22:24 +00:00
|
|
|
|
kbuild: add 'headers' target to build up uapi headers in usr/include
In Linux build system, build targets and installation targets are
separated.
Examples are:
- 'make vmlinux' -> 'make install'
- 'make modules' -> 'make modules_install'
- 'make dtbs' -> 'make dtbs_install'
- 'make vdso' -> 'make vdso_install'
The intention is to run the build targets under the normal privilege,
then the installation targets under the root privilege since we need
the write permission to the system directories.
We have 'make headers_install' but the corresponding 'make headers'
stage does not exist. The purpose of headers_install is to provide
the kernel interface to C library. So, nobody would try to install
headers to /usr/include directly.
If 'sudo make INSTALL_HDR_PATH=/usr/include headers_install' were run,
some build artifacts in the kernel tree would be owned by root because
some of uapi headers are generated by 'uapi-asm-generic', 'archheaders'
targets.
Anyway, I believe it makes sense to split the header installation into
two stages.
[1] 'make headers'
Process headers in uapi directories by scripts/headers_install.sh
and copy them to usr/include
[2] 'make headers_install'
Copy '*.h' verbatim from usr/include to $(INSTALL_HDR_PATH)/include
For the backward compatibility, 'headers_install' depends on 'headers'.
Some samples expect uapi headers in usr/include. So, the 'headers'
target is useful to build up them in the fixed location usr/include
irrespective of INSTALL_HDR_PATH.
Another benefit is to stop polluting the final destination with the
time-stamp files '.install' and '.check'. Maybe you can see them in
your toolchains.
Lastly, my main motivation is to prepare for compile-testing uapi
headers. To build something, we have to save an object and .*.cmd
somewhere. The usr/include/ will be the work directory for that.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-06-04 10:14:02 +00:00
|
|
|
PHONY += archheaders archscripts
|
2008-06-05 14:43:46 +00:00
|
|
|
|
2019-06-04 10:14:04 +00:00
|
|
|
hdr-inst := -f $(srctree)/scripts/Makefile.headersinst obj
|
2006-09-24 21:16:03 +00:00
|
|
|
|
kbuild: add 'headers' target to build up uapi headers in usr/include
In Linux build system, build targets and installation targets are
separated.
Examples are:
- 'make vmlinux' -> 'make install'
- 'make modules' -> 'make modules_install'
- 'make dtbs' -> 'make dtbs_install'
- 'make vdso' -> 'make vdso_install'
The intention is to run the build targets under the normal privilege,
then the installation targets under the root privilege since we need
the write permission to the system directories.
We have 'make headers_install' but the corresponding 'make headers'
stage does not exist. The purpose of headers_install is to provide
the kernel interface to C library. So, nobody would try to install
headers to /usr/include directly.
If 'sudo make INSTALL_HDR_PATH=/usr/include headers_install' were run,
some build artifacts in the kernel tree would be owned by root because
some of uapi headers are generated by 'uapi-asm-generic', 'archheaders'
targets.
Anyway, I believe it makes sense to split the header installation into
two stages.
[1] 'make headers'
Process headers in uapi directories by scripts/headers_install.sh
and copy them to usr/include
[2] 'make headers_install'
Copy '*.h' verbatim from usr/include to $(INSTALL_HDR_PATH)/include
For the backward compatibility, 'headers_install' depends on 'headers'.
Some samples expect uapi headers in usr/include. So, the 'headers'
target is useful to build up them in the fixed location usr/include
irrespective of INSTALL_HDR_PATH.
Another benefit is to stop polluting the final destination with the
time-stamp files '.install' and '.check'. Maybe you can see them in
your toolchains.
Lastly, my main motivation is to prepare for compile-testing uapi
headers. To build something, we have to save an object and .*.cmd
somewhere. The usr/include/ will be the work directory for that.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-06-04 10:14:02 +00:00
|
|
|
PHONY += headers
|
|
|
|
|
headers: $(version_h) scripts_unifdef uapi-asm-generic archheaders archscripts
|
2022-09-01 01:12:52 +00:00
|
|
|
$(if $(filter um, $(SRCARCH)), $(error Headers not exportable for UML))
|
2019-06-04 10:14:03 +00:00
|
|
|
$(Q)$(MAKE) $(hdr-inst)=include/uapi
|
|
|
|
|
$(Q)$(MAKE) $(hdr-inst)=arch/$(SRCARCH)/include/uapi
|
2007-02-14 08:33:02 +00:00
|
|
|
|
2019-06-04 10:13:59 +00:00
|
|
|
ifdef CONFIG_HEADERS_INSTALL
|
kbuild: add 'headers' target to build up uapi headers in usr/include
In Linux build system, build targets and installation targets are
separated.
Examples are:
- 'make vmlinux' -> 'make install'
- 'make modules' -> 'make modules_install'
- 'make dtbs' -> 'make dtbs_install'
- 'make vdso' -> 'make vdso_install'
The intention is to run the build targets under the normal privilege,
then the installation targets under the root privilege since we need
the write permission to the system directories.
We have 'make headers_install' but the corresponding 'make headers'
stage does not exist. The purpose of headers_install is to provide
the kernel interface to C library. So, nobody would try to install
headers to /usr/include directly.
If 'sudo make INSTALL_HDR_PATH=/usr/include headers_install' were run,
some build artifacts in the kernel tree would be owned by root because
some of uapi headers are generated by 'uapi-asm-generic', 'archheaders'
targets.
Anyway, I believe it makes sense to split the header installation into
two stages.
[1] 'make headers'
Process headers in uapi directories by scripts/headers_install.sh
and copy them to usr/include
[2] 'make headers_install'
Copy '*.h' verbatim from usr/include to $(INSTALL_HDR_PATH)/include
For the backward compatibility, 'headers_install' depends on 'headers'.
Some samples expect uapi headers in usr/include. So, the 'headers'
target is useful to build up them in the fixed location usr/include
irrespective of INSTALL_HDR_PATH.
Another benefit is to stop polluting the final destination with the
time-stamp files '.install' and '.check'. Maybe you can see them in
your toolchains.
Lastly, my main motivation is to prepare for compile-testing uapi
headers. To build something, we have to save an object and .*.cmd
somewhere. The usr/include/ will be the work directory for that.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-06-04 10:14:02 +00:00
|
|
|
prepare: headers
|
2019-06-04 10:13:59 +00:00
|
|
|
endif
|
2006-06-18 11:02:10 +00:00
|
|
|
|
2019-06-04 10:14:01 +00:00
|
|
|
PHONY += scripts_unifdef
|
|
|
|
|
scripts_unifdef: scripts_basic
|
|
|
|
|
$(Q)$(MAKE) $(build)=scripts scripts/unifdef
|
|
|
|
|
|
2021-07-29 00:12:54 +00:00
|
|
|
# ---------------------------------------------------------------------------
|
|
|
|
|
# Install
|
|
|
|
|
|
|
|
|
|
# Many distributions have the custom install script, /sbin/installkernel.
|
2022-04-26 03:53:18 +00:00
|
|
|
# If DKMS is installed, 'make install' will eventually recurse back
|
|
|
|
|
# to this Makefile to build and install external modules.
|
2021-07-29 00:12:54 +00:00
|
|
|
# Cancel sub_make_done so that options such as M=, V=, etc. are parsed.
|
|
|
|
|
|
2022-05-03 02:47:16 +00:00
|
|
|
quiet_cmd_install = INSTALL $(INSTALL_PATH)
|
|
|
|
|
cmd_install = unset sub_make_done; $(srctree)/scripts/install.sh
|
2021-07-29 00:12:54 +00:00
|
|
|
|
kbuild: unify vdso_install rules
Currently, there is no standard implementation for vdso_install,
leading to various issues:
1. Code duplication
Many architectures duplicate similar code just for copying files
to the install destination.
Some architectures (arm, sparc, x86) create build-id symlinks,
introducing more code duplication.
2. Unintended updates of in-tree build artifacts
The vdso_install rule depends on the vdso files to install.
It may update in-tree build artifacts. This can be problematic,
as explained in commit 19514fc665ff ("arm, kbuild: make
"make install" not depend on vmlinux").
3. Broken code in some architectures
Makefile code is often copied from one architecture to another
without proper adaptation.
'make vdso_install' for parisc does not work.
'make vdso_install' for s390 installs vdso64, but not vdso32.
To address these problems, this commit introduces a generic vdso_install
rule.
Architectures that support vdso_install need to define vdso-install-y
in arch/*/Makefile. vdso-install-y lists the files to install.
For example, arch/x86/Makefile looks like this:
vdso-install-$(CONFIG_X86_64) += arch/x86/entry/vdso/vdso64.so.dbg
vdso-install-$(CONFIG_X86_X32_ABI) += arch/x86/entry/vdso/vdsox32.so.dbg
vdso-install-$(CONFIG_X86_32) += arch/x86/entry/vdso/vdso32.so.dbg
vdso-install-$(CONFIG_IA32_EMULATION) += arch/x86/entry/vdso/vdso32.so.dbg
These files will be installed to $(MODLIB)/vdso/ with the .dbg suffix,
if exists, stripped away.
vdso-install-y can optionally take the second field after the colon
separator. This is needed because some architectures install a vdso
file as a different base name.
The following is a snippet from arch/arm64/Makefile.
vdso-install-$(CONFIG_COMPAT_VDSO) += arch/arm64/kernel/vdso32/vdso.so.dbg:vdso32.so
This will rename vdso.so.dbg to vdso32.so during installation. If such
architectures change their implementation so that the base names match,
this workaround will go away.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Acked-by: Sven Schnelle <svens@linux.ibm.com> # s390
Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
Reviewed-by: Guo Ren <guoren@kernel.org>
Acked-by: Helge Deller <deller@gmx.de> # parisc
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2023-10-14 10:54:35 +00:00
|
|
|
# ---------------------------------------------------------------------------
|
|
|
|
|
# vDSO install
|
|
|
|
|
|
|
|
|
|
PHONY += vdso_install
|
|
|
|
|
vdso_install: export INSTALL_FILES = $(vdso-install-y)
|
|
|
|
|
vdso_install:
|
|
|
|
|
$(Q)$(MAKE) -f $(srctree)/scripts/Makefile.vdsoinst
|
|
|
|
|
|
2021-05-12 06:52:00 +00:00
|
|
|
# ---------------------------------------------------------------------------
|
|
|
|
|
# Tools
|
|
|
|
|
|
2022-04-18 16:50:36 +00:00
|
|
|
ifdef CONFIG_OBJTOOL
|
kbuild: remove libelf checks from top Makefile
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: Masahiro Yamada <masahiroy@kernel.org>
Acked-by: Andrii Nakryiko <andrii@kernel.org>
2021-05-12 06:52:01 +00:00
|
|
|
prepare: tools/objtool
|
|
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
ifdef CONFIG_BPF
|
|
|
|
|
ifdef CONFIG_DEBUG_INFO_BTF
|
|
|
|
|
prepare: tools/bpf/resolve_btfids
|
|
|
|
|
endif
|
|
|
|
|
endif
|
|
|
|
|
|
2024-07-17 18:28:19 +00:00
|
|
|
# The tools build system is not a part of Kbuild and tends to introduce
|
|
|
|
|
# its own unique issues. If you need to integrate a new tool into Kbuild,
|
|
|
|
|
# please consider locating that tool outside the tools/ tree and using the
|
|
|
|
|
# standard Kbuild "hostprogs" syntax instead of adding a new tools/* entry
|
|
|
|
|
# here. See Documentation/kbuild/makefiles.rst for details.
|
|
|
|
|
|
kbuild: remove libelf checks from top Makefile
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: Masahiro Yamada <masahiroy@kernel.org>
Acked-by: Andrii Nakryiko <andrii@kernel.org>
2021-05-12 06:52:01 +00:00
|
|
|
PHONY += resolve_btfids_clean
|
|
|
|
|
|
|
|
|
|
resolve_btfids_O = $(abspath $(objtree))/tools/bpf/resolve_btfids
|
|
|
|
|
|
|
|
|
|
# tools/bpf/resolve_btfids directory might not exist
|
|
|
|
|
# in output directory, skip its clean in that case
|
|
|
|
|
resolve_btfids_clean:
|
|
|
|
|
ifneq ($(wildcard $(resolve_btfids_O)),)
|
|
|
|
|
$(Q)$(MAKE) -sC $(srctree)/tools/bpf/resolve_btfids O=$(resolve_btfids_O) clean
|
|
|
|
|
endif
|
|
|
|
|
|
2021-05-12 06:52:00 +00:00
|
|
|
# Clear a bunch of variables before executing the submake
|
|
|
|
|
ifeq ($(quiet),silent_)
|
|
|
|
|
tools_silent=s
|
|
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
tools/: FORCE
|
|
|
|
|
$(Q)mkdir -p $(objtree)/tools
|
|
|
|
|
$(Q)$(MAKE) LDFLAGS= MAKEFLAGS="$(tools_silent) $(filter --j% -j,$(MAKEFLAGS))" O=$(abspath $(objtree)) subdir=tools -C $(srctree)/tools/
|
|
|
|
|
|
|
|
|
|
tools/%: FORCE
|
|
|
|
|
$(Q)mkdir -p $(objtree)/tools
|
|
|
|
|
$(Q)$(MAKE) LDFLAGS= MAKEFLAGS="$(tools_silent) $(filter --j% -j,$(MAKEFLAGS))" O=$(abspath $(objtree)) subdir=tools -C $(srctree)/tools/ $*
|
|
|
|
|
|
2014-08-07 19:07:46 +00:00
|
|
|
# ---------------------------------------------------------------------------
|
|
|
|
|
# Kernel selftest
|
|
|
|
|
|
|
|
|
|
PHONY += kselftest
|
2022-07-13 06:33:43 +00:00
|
|
|
kselftest: headers
|
2017-09-06 22:44:35 +00:00
|
|
|
$(Q)$(MAKE) -C $(srctree)/tools/testing/selftests run_tests
|
2014-08-07 19:07:46 +00:00
|
|
|
|
2022-07-13 06:33:43 +00:00
|
|
|
kselftest-%: headers FORCE
|
2019-09-26 22:40:14 +00:00
|
|
|
$(Q)$(MAKE) -C $(srctree)/tools/testing/selftests $*
|
2015-10-08 02:41:18 +00:00
|
|
|
|
2016-01-08 07:27:34 +00:00
|
|
|
PHONY += kselftest-merge
|
|
|
|
|
kselftest-merge:
|
|
|
|
|
$(if $(wildcard $(objtree)/.config),, $(error No .config exists, config your kernel first!))
|
2023-10-04 12:48:37 +00:00
|
|
|
$(Q)find $(srctree)/tools/testing/selftests -name config -o -name config.$(UTS_MACHINE) | \
|
2023-10-04 12:48:36 +00:00
|
|
|
xargs $(srctree)/scripts/kconfig/merge_config.sh -y -m $(objtree)/.config
|
2019-08-21 07:03:48 +00:00
|
|
|
$(Q)$(MAKE) -f $(srctree)/Makefile olddefconfig
|
2016-01-08 07:27:34 +00:00
|
|
|
|
2018-01-10 21:19:37 +00:00
|
|
|
# ---------------------------------------------------------------------------
|
|
|
|
|
# Devicetree files
|
|
|
|
|
|
|
|
|
|
ifneq ($(wildcard $(srctree)/arch/$(SRCARCH)/boot/dts/),)
|
|
|
|
|
dtstree := arch/$(SRCARCH)/boot/dts
|
|
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
ifneq ($(dtstree),)
|
|
|
|
|
|
2022-07-24 09:59:19 +00:00
|
|
|
%.dtb: dtbs_prepare
|
2021-12-08 21:39:16 +00:00
|
|
|
$(Q)$(MAKE) $(build)=$(dtstree) $(dtstree)/$@
|
2018-01-10 21:19:37 +00:00
|
|
|
|
2022-07-24 09:59:19 +00:00
|
|
|
%.dtbo: dtbs_prepare
|
2021-12-08 21:39:16 +00:00
|
|
|
$(Q)$(MAKE) $(build)=$(dtstree) $(dtstree)/$@
|
2021-01-29 07:24:08 +00:00
|
|
|
|
2022-07-24 09:59:19 +00:00
|
|
|
PHONY += dtbs dtbs_prepare dtbs_install dtbs_check
|
|
|
|
|
dtbs: dtbs_prepare
|
2024-01-09 12:07:34 +00:00
|
|
|
$(Q)$(MAKE) $(build)=$(dtstree) need-dtbslist=1
|
2018-01-10 21:19:37 +00:00
|
|
|
|
2022-07-24 09:59:19 +00:00
|
|
|
# include/config/kernel.release is actually needed when installing DTBs because
|
|
|
|
|
# INSTALL_DTBS_PATH contains $(KERNELRELEASE). However, we do not want to make
|
|
|
|
|
# dtbs_install depend on it as dtbs_install may run as root.
|
|
|
|
|
dtbs_prepare: include/config/kernel.release scripts_dtc
|
|
|
|
|
|
2021-12-08 21:39:16 +00:00
|
|
|
ifneq ($(filter dtbs_check, $(MAKECMDGOALS)),)
|
2020-03-04 03:20:37 +00:00
|
|
|
export CHECK_DTBS=y
|
2022-12-20 01:32:33 +00:00
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
ifneq ($(CHECK_DTBS),)
|
2024-04-05 22:56:03 +00:00
|
|
|
dtbs_prepare: dt_binding_schemas
|
2020-03-04 03:20:36 +00:00
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
dtbs_check: dtbs
|
2018-09-06 18:26:07 +00:00
|
|
|
|
2018-01-10 21:19:37 +00:00
|
|
|
dtbs_install:
|
2024-01-09 12:07:35 +00:00
|
|
|
$(Q)$(MAKE) -f $(srctree)/scripts/Makefile.dtbinst obj=$(dtstree)
|
2018-01-10 21:19:37 +00:00
|
|
|
|
|
|
|
|
ifdef CONFIG_OF_EARLY_FLATTREE
|
|
|
|
|
all: dtbs
|
|
|
|
|
endif
|
|
|
|
|
|
2024-09-23 07:56:03 +00:00
|
|
|
ifdef CONFIG_GENERIC_BUILTIN_DTB
|
|
|
|
|
vmlinux: dtbs
|
|
|
|
|
endif
|
|
|
|
|
|
2018-01-10 21:19:37 +00:00
|
|
|
endif
|
|
|
|
|
|
|
|
|
|
PHONY += scripts_dtc
|
|
|
|
|
scripts_dtc: scripts_basic
|
|
|
|
|
$(Q)$(MAKE) $(build)=scripts/dtc
|
|
|
|
|
|
2020-03-04 03:20:37 +00:00
|
|
|
ifneq ($(filter dt_binding_check, $(MAKECMDGOALS)),)
|
2024-04-05 22:56:03 +00:00
|
|
|
export CHECK_DTBS=y
|
2020-03-04 03:20:37 +00:00
|
|
|
endif
|
|
|
|
|
|
2024-04-05 22:56:03 +00:00
|
|
|
PHONY += dt_binding_check dt_binding_schemas
|
|
|
|
|
dt_binding_check: dt_binding_schemas scripts_dtc
|
|
|
|
|
$(Q)$(MAKE) $(build)=Documentation/devicetree/bindings $@
|
|
|
|
|
|
|
|
|
|
dt_binding_schemas:
|
2018-09-06 18:26:07 +00:00
|
|
|
$(Q)$(MAKE) $(build)=Documentation/devicetree/bindings
|
|
|
|
|
|
2022-06-30 21:37:22 +00:00
|
|
|
PHONY += dt_compatible_check
|
2024-04-05 22:56:03 +00:00
|
|
|
dt_compatible_check: dt_binding_schemas
|
2022-06-30 21:37:22 +00:00
|
|
|
$(Q)$(MAKE) $(build)=Documentation/devicetree/bindings $@
|
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
# ---------------------------------------------------------------------------
|
|
|
|
|
# Modules
|
|
|
|
|
|
|
|
|
|
ifdef CONFIG_MODULES
|
|
|
|
|
|
2006-06-24 22:07:55 +00:00
|
|
|
# By default, build modules as well
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2010-03-10 11:28:58 +00:00
|
|
|
all: modules
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2020-05-31 08:47:06 +00:00
|
|
|
# When we're building modules with modversions, we need to consider
|
|
|
|
|
# the built-in objects during the descend as well, in order to
|
|
|
|
|
# make sure the checksums are up to date before we record them.
|
|
|
|
|
ifdef CONFIG_MODVERSIONS
|
|
|
|
|
KBUILD_BUILTIN := 1
|
|
|
|
|
endif
|
|
|
|
|
|
2014-04-28 07:32:43 +00:00
|
|
|
# Build modules
|
2007-12-07 12:04:30 +00:00
|
|
|
#
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2023-01-25 18:30:47 +00:00
|
|
|
# *.ko are usually independent of vmlinux, but CONFIG_DEBUG_INFO_BTF_MODULES
|
2022-09-24 18:19:13 +00:00
|
|
|
# is an exception.
|
|
|
|
|
ifdef CONFIG_DEBUG_INFO_BTF_MODULES
|
2023-01-10 05:48:00 +00:00
|
|
|
KBUILD_BUILTIN := 1
|
2022-09-24 18:19:13 +00:00
|
|
|
modules: vmlinux
|
|
|
|
|
endif
|
2020-06-01 05:57:00 +00:00
|
|
|
|
2022-09-24 18:19:13 +00:00
|
|
|
modules: modules_prepare
|
2019-06-23 16:13:28 +00:00
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
# Target to prepare building external modules
|
2018-11-29 03:56:30 +00:00
|
|
|
modules_prepare: prepare
|
2020-09-08 04:27:08 +00:00
|
|
|
$(Q)$(MAKE) $(build)=scripts scripts/module.lds
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2023-06-15 11:17:43 +00:00
|
|
|
endif # CONFIG_MODULES
|
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
###
|
|
|
|
|
# Cleaning is done on three levels.
|
|
|
|
|
# make clean Delete most generated files
|
|
|
|
|
# Leave enough to build external modules
|
|
|
|
|
# make mrproper Delete the current configuration, and all generated files
|
|
|
|
|
# make distclean Remove editor backup files, patch leftover files and the like
|
|
|
|
|
|
|
|
|
|
# Directories & files removed with 'make clean'
|
2023-08-19 11:43:01 +00:00
|
|
|
CLEAN_FILES += vmlinux.symvers modules-only.symvers \
|
kbuild: wire up the build rule of compile_commands.json to Makefile
Currently, you need to manually run scripts/gen_compile_commands.py
to create compile_commands.json. It parses all the .*.cmd files found
under the specified directory.
If you rebuild the kernel over again without 'make clean',
.*.cmd files from older builds will create stale entries in
compile_commands.json.
This commit wires up the compile_commands.json rule to Makefile, and
makes it parse only the .*.cmd files involved in the current build.
Pass $(KBUILD_VMLINUX_OBJS), $(KBUILD_VMLINUX_LIBS), and modules.order
to the script. The objects or archives linked to vmlinux are listed in
$(KBUILD_VMLINUX_OBJS) or $(KBUILD_VMLINUX_LIBS). All the modules are
listed in modules.order.
You can create compile_commands.json from Make:
$ make -j$(nproc) CC=clang compile_commands.json
You can also build vmlinux, modules, and compile_commands.json all
together in a single command:
$ make -j$(nproc) CC=clang all compile_commands.json
It works for M= builds as well. In this case, compile_commands.json
is created in the top directory of the external module.
This is convenient, but it has a drawback; the coverage of the
compile_commands.json is reduced because only the objects linked to
vmlinux or modules are handled. For example, the following C files are
not included in the compile_commands.json:
- Decompressor source files (arch/*/boot/)
- VDSO source files
- C files used to generate intermediates (e.g. kernel/bounds.c)
- Standalone host programs
I think it is fine for most developers because our main interest is
the kernel-space code.
If you want to cover all the compiled C files, please build the kernel,
then run the script manually as you did before:
$ make clean # if you want to remove stale .cmd files [optional]
$ make -j$(nproc) CC=clang
$ scripts/gen_compile_commands.py
Here is a note for out-of-tree builds. 'make compile_commands.json'
works with O= option, but please notice compile_commands.json is
created in the object tree instead of the source tree.
Some people may want to have compile_commands.json in the source tree
because Clang Tools searches for it through all parent paths of the
first input source file.
However, you cannot do this for O= builds. Kbuild should never generate
any build artifact in the source tree when O= is given because the
source tree might be read-only. Any write attempt to the source tree
is monitored and the violation may be reported. See the commit log of
8ef14c2c41d9.
So, the only possible way is to create compile_commands.json in the
object tree, then specify '-p <build-path>' when you use clang-check,
clang-tidy, etc.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Acked-by: Nick Desaulniers <ndesaulniers@google.com>
2020-08-22 14:56:16 +00:00
|
|
|
modules.builtin modules.builtin.modinfo modules.nsdeps \
|
kbuild: generate offset range data for builtin modules
Create file module.builtin.ranges that can be used to find where
built-in modules are located by their addresses. This will be useful for
tracing tools to find what functions are for various built-in modules.
The offset range data for builtin modules is generated using:
- modules.builtin: associates object files with module names
- vmlinux.map: provides load order of sections and offset of first member
per section
- vmlinux.o.map: provides offset of object file content per section
- .*.cmd: build cmd file with KBUILD_MODFILE
The generated data will look like:
.text 00000000-00000000 = _text
.text 0000baf0-0000cb10 amd_uncore
.text 0009bd10-0009c8e0 iosf_mbi
...
.text 00b9f080-00ba011a intel_skl_int3472_discrete
.text 00ba0120-00ba03c0 intel_skl_int3472_discrete intel_skl_int3472_tps68470
.text 00ba03c0-00ba08d6 intel_skl_int3472_tps68470
...
.data 00000000-00000000 = _sdata
.data 0000f020-0000f680 amd_uncore
For each ELF section, it lists the offset of the first symbol. This can
be used to determine the base address of the section at runtime.
Next, it lists (in strict ascending order) offset ranges in that section
that cover the symbols of one or more builtin modules. Multiple ranges
can apply to a single module, and ranges can be shared between modules.
The CONFIG_BUILTIN_MODULE_RANGES option controls whether offset range data
is generated for kernel modules that are built into the kernel image.
How it works:
1. The modules.builtin file is parsed to obtain a list of built-in
module names and their associated object names (the .ko file that
the module would be in if it were a loadable module, hereafter
referred to as <kmodfile>). This object name can be used to
identify objects in the kernel compile because any C or assembler
code that ends up into a built-in module will have the option
-DKBUILD_MODFILE=<kmodfile> present in its build command, and those
can be found in the .<obj>.cmd file in the kernel build tree.
If an object is part of multiple modules, they will all be listed
in the KBUILD_MODFILE option argument.
This allows us to conclusively determine whether an object in the
kernel build belong to any modules, and which.
2. The vmlinux.map is parsed next to determine the base address of each
top level section so that all addresses into the section can be
turned into offsets. This makes it possible to handle sections
getting loaded at different addresses at system boot.
We also determine an 'anchor' symbol at the beginning of each
section to make it possible to calculate the true base address of
a section at runtime (i.e. symbol address - symbol offset).
We collect start addresses of sections that are included in the top
level section. This is used when vmlinux is linked using vmlinux.o,
because in that case, we need to look at the vmlinux.o linker map to
know what object a symbol is found in.
And finally, we process each symbol that is listed in vmlinux.map
(or vmlinux.o.map) based on the following structure:
vmlinux linked from vmlinux.a:
vmlinux.map:
<top level section>
<included section> -- might be same as top level section)
<object> -- built-in association known
<symbol> -- belongs to module(s) object belongs to
...
vmlinux linked from vmlinux.o:
vmlinux.map:
<top level section>
<included section> -- might be same as top level section)
vmlinux.o -- need to use vmlinux.o.map
<symbol> -- ignored
...
vmlinux.o.map:
<section>
<object> -- built-in association known
<symbol> -- belongs to module(s) object belongs to
...
3. As sections, objects, and symbols are processed, offset ranges are
constructed in a straight-forward way:
- If the symbol belongs to one or more built-in modules:
- If we were working on the same module(s), extend the range
to include this object
- If we were working on another module(s), close that range,
and start the new one
- If the symbol does not belong to any built-in modules:
- If we were working on a module(s) range, close that range
Signed-off-by: Kris Van Hees <kris.van.hees@oracle.com>
Reviewed-by: Nick Alcock <nick.alcock@oracle.com>
Reviewed-by: Alan Maguire <alan.maguire@oracle.com>
Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org>
Tested-by: Sam James <sam@gentoo.org>
Reviewed-by: Sami Tolvanen <samitolvanen@google.com>
Tested-by: Sami Tolvanen <samitolvanen@google.com>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-09-06 14:45:03 +00:00
|
|
|
modules.builtin.ranges vmlinux.o.map \
|
kbuild: Remove support for Clang's ThinLTO caching
There is an issue in clang's ThinLTO caching (enabled for the kernel via
'--thinlto-cache-dir') with .incbin, which the kernel occasionally uses
to include data within the kernel, such as the .config file for
/proc/config.gz. For example, when changing the .config and rebuilding
vmlinux, the copy of .config in vmlinux does not match the copy of
.config in the build folder:
$ echo 'CONFIG_LTO_NONE=n
CONFIG_LTO_CLANG_THIN=y
CONFIG_IKCONFIG=y
CONFIG_HEADERS_INSTALL=y' >kernel/configs/repro.config
$ make -skj"$(nproc)" ARCH=x86_64 LLVM=1 clean defconfig repro.config vmlinux
...
$ grep CONFIG_HEADERS_INSTALL .config
CONFIG_HEADERS_INSTALL=y
$ scripts/extract-ikconfig vmlinux | grep CONFIG_HEADERS_INSTALL
CONFIG_HEADERS_INSTALL=y
$ scripts/config -d HEADERS_INSTALL
$ make -kj"$(nproc)" ARCH=x86_64 LLVM=1 vmlinux
...
UPD kernel/config_data
GZIP kernel/config_data.gz
CC kernel/configs.o
...
LD vmlinux
...
$ grep CONFIG_HEADERS_INSTALL .config
# CONFIG_HEADERS_INSTALL is not set
$ scripts/extract-ikconfig vmlinux | grep CONFIG_HEADERS_INSTALL
CONFIG_HEADERS_INSTALL=y
Without '--thinlto-cache-dir' or when using full LTO, this issue does
not occur.
Benchmarking incremental builds on a few different machines with and
without the cache shows a 20% increase in incremental build time without
the cache when measured by touching init/main.c and running 'make all'.
ARCH=arm64 defconfig + CONFIG_LTO_CLANG_THIN=y on an arm64 host:
Benchmark 1: With ThinLTO cache
Time (mean ± σ): 56.347 s ± 0.163 s [User: 83.768 s, System: 24.661 s]
Range (min … max): 56.109 s … 56.594 s 10 runs
Benchmark 2: Without ThinLTO cache
Time (mean ± σ): 67.740 s ± 0.479 s [User: 718.458 s, System: 31.797 s]
Range (min … max): 67.059 s … 68.556 s 10 runs
Summary
With ThinLTO cache ran
1.20 ± 0.01 times faster than Without ThinLTO cache
ARCH=x86_64 defconfig + CONFIG_LTO_CLANG_THIN=y on an x86_64 host:
Benchmark 1: With ThinLTO cache
Time (mean ± σ): 85.772 s ± 0.252 s [User: 91.505 s, System: 8.408 s]
Range (min … max): 85.447 s … 86.244 s 10 runs
Benchmark 2: Without ThinLTO cache
Time (mean ± σ): 103.833 s ± 0.288 s [User: 232.058 s, System: 8.569 s]
Range (min … max): 103.286 s … 104.124 s 10 runs
Summary
With ThinLTO cache ran
1.21 ± 0.00 times faster than Without ThinLTO cache
While it is unfortunate to take this performance improvement off the
table, correctness is more important. If/when this is fixed in LLVM, it
can potentially be brought back in a conditional manner. Alternatively,
a developer can just disable LTO if doing incremental compiles quickly
is important, as a full compile cycle can still take over a minute even
with the cache and it is unlikely that LTO will result in functional
differences for a kernel change.
Cc: stable@vger.kernel.org
Fixes: dc5723b02e52 ("kbuild: add support for Clang LTO")
Reported-by: Yifan Hong <elsk@google.com>
Closes: https://github.com/ClangBuiltLinux/linux/issues/2021
Reported-by: Masami Hiramatsu <mhiramat@kernel.org>
Closes: https://lore.kernel.org/r/20220327115526.cc4b0ff55fc53c97683c3e4d@kernel.org/
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2024-05-01 22:55:25 +00:00
|
|
|
compile_commands.json rust/test \
|
2024-09-23 07:56:03 +00:00
|
|
|
rust-project.json .vmlinux.objs .vmlinux.export.c \
|
|
|
|
|
.builtin-dtbs-list .builtin-dtb.S
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
|
# Directories & files removed with 'make mrproper'
|
2020-05-04 08:08:07 +00:00
|
|
|
MRPROPER_FILES += include/config include/generated \
|
2022-05-28 15:47:02 +00:00
|
|
|
arch/$(SRCARCH)/include/generated .objdiff \
|
2024-07-20 09:18:12 +00:00
|
|
|
debian snap tar-install PKGBUILD pacman \
|
2020-05-04 08:08:07 +00:00
|
|
|
.config .config.old .version \
|
2019-07-15 14:01:49 +00:00
|
|
|
Module.symvers \
|
2021-12-14 02:53:48 +00:00
|
|
|
certs/signing_key.pem \
|
2021-04-09 14:35:05 +00:00
|
|
|
certs/x509.genkey \
|
|
|
|
|
vmlinux-gdb.py \
|
2023-09-30 10:38:47 +00:00
|
|
|
rpmbuild \
|
2023-01-07 09:45:45 +00:00
|
|
|
rust/libmacros.so
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
|
# clean - Delete most, but leave enough to build external modules
|
|
|
|
|
#
|
2024-04-27 15:32:53 +00:00
|
|
|
clean: private rm-files := $(CLEAN_FILES)
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2019-08-10 15:53:05 +00:00
|
|
|
PHONY += archclean vmlinuxclean
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2012-10-29 11:23:02 +00:00
|
|
|
vmlinuxclean:
|
|
|
|
|
$(Q)$(CONFIG_SHELL) $(srctree)/scripts/link-vmlinux.sh clean
|
2016-08-24 12:29:21 +00:00
|
|
|
$(Q)$(if $(ARCH_POSTLINK), $(MAKE) -f $(ARCH_POSTLINK) clean)
|
2012-10-29 11:23:02 +00:00
|
|
|
|
2021-02-05 12:40:20 +00:00
|
|
|
clean: archclean vmlinuxclean resolve_btfids_clean
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
|
# mrproper - Delete all generated files, including .config
|
|
|
|
|
#
|
2024-04-27 15:32:53 +00:00
|
|
|
mrproper: private rm-files := $(MRPROPER_FILES)
|
2017-05-14 14:50:01 +00:00
|
|
|
mrproper-dirs := $(addprefix _mrproper_,scripts)
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2019-01-14 08:29:29 +00:00
|
|
|
PHONY += $(mrproper-dirs) mrproper
|
2005-04-16 22:20:36 +00:00
|
|
|
$(mrproper-dirs):
|
|
|
|
|
$(Q)$(MAKE) $(clean)=$(patsubst _mrproper_%,%,$@)
|
|
|
|
|
|
2019-01-14 08:29:29 +00:00
|
|
|
mrproper: clean $(mrproper-dirs)
|
2005-04-16 22:20:36 +00:00
|
|
|
$(call cmd,rmfiles)
|
2021-07-03 14:42:57 +00:00
|
|
|
@find . $(RCS_FIND_IGNORE) \
|
|
|
|
|
\( -name '*.rmeta' \) \
|
|
|
|
|
-type f -print | xargs rm -f
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
|
# distclean
|
|
|
|
|
#
|
2006-03-05 22:14:10 +00:00
|
|
|
PHONY += distclean
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
|
distclean: mrproper
|
2021-05-04 10:10:56 +00:00
|
|
|
@find . $(RCS_FIND_IGNORE) \
|
2006-06-24 22:07:55 +00:00
|
|
|
\( -name '*.orig' -o -name '*.rej' -o -name '*~' \
|
2017-01-22 14:02:32 +00:00
|
|
|
-o -name '*.bak' -o -name '#*#' -o -name '*%' \
|
2021-05-04 10:10:57 +00:00
|
|
|
-o -name 'core' -o -name tags -o -name TAGS -o -name 'cscope*' \
|
|
|
|
|
-o -name GPATH -o -name GRTAGS -o -name GSYMS -o -name GTAGS \) \
|
2005-04-16 22:20:36 +00:00
|
|
|
-type f -print | xargs rm -f
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
# Packaging of the kernel to various formats
|
|
|
|
|
# ---------------------------------------------------------------------------
|
|
|
|
|
|
2010-06-07 10:44:25 +00:00
|
|
|
%src-pkg: FORCE
|
2019-08-21 07:02:04 +00:00
|
|
|
$(Q)$(MAKE) -f $(srctree)/scripts/Makefile.package $@
|
2006-06-09 05:12:37 +00:00
|
|
|
%pkg: include/config/kernel.release FORCE
|
2019-08-21 07:02:04 +00:00
|
|
|
$(Q)$(MAKE) -f $(srctree)/scripts/Makefile.package $@
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
|
# Brief documentation of the typical targets used
|
|
|
|
|
# ---------------------------------------------------------------------------
|
|
|
|
|
|
2008-04-06 20:16:07 +00:00
|
|
|
boards := $(wildcard $(srctree)/arch/$(SRCARCH)/configs/*_defconfig)
|
2014-10-28 13:18:20 +00:00
|
|
|
boards := $(sort $(notdir $(boards)))
|
2008-04-06 20:16:07 +00:00
|
|
|
board-dirs := $(dir $(wildcard $(srctree)/arch/$(SRCARCH)/configs/*/*_defconfig))
|
|
|
|
|
board-dirs := $(sort $(notdir $(board-dirs:/=)))
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2016-03-13 00:39:55 +00:00
|
|
|
PHONY += help
|
2005-04-16 22:20:36 +00:00
|
|
|
help:
|
|
|
|
|
@echo 'Cleaning targets:'
|
2006-12-12 18:09:40 +00:00
|
|
|
@echo ' clean - Remove most generated files but keep the config and'
|
2006-09-24 12:01:08 +00:00
|
|
|
@echo ' enough build support to build external modules'
|
2006-12-12 18:09:40 +00:00
|
|
|
@echo ' mrproper - Remove all generated files + config + various backup files'
|
2006-09-24 12:01:08 +00:00
|
|
|
@echo ' distclean - mrproper + remove editor backup and patch files'
|
2005-04-16 22:20:36 +00:00
|
|
|
@echo ''
|
|
|
|
|
@$(MAKE) -f $(srctree)/scripts/kconfig/Makefile help
|
|
|
|
|
@echo ''
|
|
|
|
|
@echo 'Other generic targets:'
|
|
|
|
|
@echo ' all - Build all targets marked with [*]'
|
|
|
|
|
@echo '* vmlinux - Build the bare kernel'
|
|
|
|
|
@echo '* modules - Build all modules'
|
2005-11-23 19:11:34 +00:00
|
|
|
@echo ' modules_install - Install all modules to INSTALL_MOD_PATH (default: /)'
|
kbuild: unify vdso_install rules
Currently, there is no standard implementation for vdso_install,
leading to various issues:
1. Code duplication
Many architectures duplicate similar code just for copying files
to the install destination.
Some architectures (arm, sparc, x86) create build-id symlinks,
introducing more code duplication.
2. Unintended updates of in-tree build artifacts
The vdso_install rule depends on the vdso files to install.
It may update in-tree build artifacts. This can be problematic,
as explained in commit 19514fc665ff ("arm, kbuild: make
"make install" not depend on vmlinux").
3. Broken code in some architectures
Makefile code is often copied from one architecture to another
without proper adaptation.
'make vdso_install' for parisc does not work.
'make vdso_install' for s390 installs vdso64, but not vdso32.
To address these problems, this commit introduces a generic vdso_install
rule.
Architectures that support vdso_install need to define vdso-install-y
in arch/*/Makefile. vdso-install-y lists the files to install.
For example, arch/x86/Makefile looks like this:
vdso-install-$(CONFIG_X86_64) += arch/x86/entry/vdso/vdso64.so.dbg
vdso-install-$(CONFIG_X86_X32_ABI) += arch/x86/entry/vdso/vdsox32.so.dbg
vdso-install-$(CONFIG_X86_32) += arch/x86/entry/vdso/vdso32.so.dbg
vdso-install-$(CONFIG_IA32_EMULATION) += arch/x86/entry/vdso/vdso32.so.dbg
These files will be installed to $(MODLIB)/vdso/ with the .dbg suffix,
if exists, stripped away.
vdso-install-y can optionally take the second field after the colon
separator. This is needed because some architectures install a vdso
file as a different base name.
The following is a snippet from arch/arm64/Makefile.
vdso-install-$(CONFIG_COMPAT_VDSO) += arch/arm64/kernel/vdso32/vdso.so.dbg:vdso32.so
This will rename vdso.so.dbg to vdso32.so during installation. If such
architectures change their implementation so that the base names match,
this workaround will go away.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Acked-by: Sven Schnelle <svens@linux.ibm.com> # s390
Reviewed-by: Nicolas Schier <nicolas@fjasle.eu>
Reviewed-by: Guo Ren <guoren@kernel.org>
Acked-by: Helge Deller <deller@gmx.de> # parisc
Acked-by: Catalin Marinas <catalin.marinas@arm.com>
Acked-by: Russell King (Oracle) <rmk+kernel@armlinux.org.uk>
2023-10-14 10:54:35 +00:00
|
|
|
@echo ' vdso_install - Install unstripped vdso to INSTALL_MOD_PATH (default: /)'
|
2005-04-16 22:20:36 +00:00
|
|
|
@echo ' dir/ - Build all files in dir and below'
|
2015-12-10 16:35:19 +00:00
|
|
|
@echo ' dir/file.[ois] - Build specified target only'
|
2017-04-24 20:04:58 +00:00
|
|
|
@echo ' dir/file.ll - Build the LLVM assembly file'
|
|
|
|
|
@echo ' (requires compiler support for LLVM assembly generation)'
|
2010-01-13 17:31:44 +00:00
|
|
|
@echo ' dir/file.lst - Build specified mixed source/assembly target only'
|
|
|
|
|
@echo ' (requires a recent binutils and recent build (System.map))'
|
2005-07-08 00:56:08 +00:00
|
|
|
@echo ' dir/file.ko - Build module including final link'
|
2009-04-24 16:35:23 +00:00
|
|
|
@echo ' modules_prepare - Set up for building external modules'
|
2005-04-16 22:20:36 +00:00
|
|
|
@echo ' tags/TAGS - Generate tags file for editors'
|
|
|
|
|
@echo ' cscope - Generate cscope index'
|
2011-01-14 12:07:05 +00:00
|
|
|
@echo ' gtags - Generate GNU GLOBAL index'
|
2014-07-11 13:57:24 +00:00
|
|
|
@echo ' kernelrelease - Output the release version string (use with make -s)'
|
|
|
|
|
@echo ' kernelversion - Output the version stored in Makefile (use with make -s)'
|
|
|
|
|
@echo ' image_name - Output the image name (use with make -s)'
|
2008-06-20 22:24:17 +00:00
|
|
|
@echo ' headers_install - Install sanitised kernel headers to INSTALL_HDR_PATH'; \
|
2007-01-29 12:47:01 +00:00
|
|
|
echo ' (default: $(INSTALL_HDR_PATH))'; \
|
2008-06-20 22:24:17 +00:00
|
|
|
echo ''
|
2017-05-08 22:55:08 +00:00
|
|
|
@echo 'Static analysers:'
|
2023-11-20 18:37:19 +00:00
|
|
|
@echo ' checkstack - Generate a list of stack hogs and consider all functions'
|
|
|
|
|
@echo ' with a stack size larger than MINSTACKSIZE (default: 100)'
|
2007-11-14 20:34:55 +00:00
|
|
|
@echo ' versioncheck - Sanity check on version.h usage'
|
2007-11-04 20:01:55 +00:00
|
|
|
@echo ' includecheck - Check for duplicate included header files'
|
2010-06-06 15:15:01 +00:00
|
|
|
@echo ' headerdep - Detect inclusion cycles in headers'
|
2017-11-14 09:47:20 +00:00
|
|
|
@echo ' coccicheck - Check with Coccinelle'
|
2020-08-22 14:56:18 +00:00
|
|
|
@echo ' clang-analyzer - Check with clang static analyzer'
|
|
|
|
|
@echo ' clang-tidy - Check with clang-tidy'
|
2010-06-06 15:15:01 +00:00
|
|
|
@echo ''
|
2019-09-06 10:32:32 +00:00
|
|
|
@echo 'Tools:'
|
|
|
|
|
@echo ' nsdeps - Generate missing symbol namespace dependencies'
|
|
|
|
|
@echo ''
|
2017-05-08 22:55:08 +00:00
|
|
|
@echo 'Kernel selftest:'
|
2020-03-30 18:07:11 +00:00
|
|
|
@echo ' kselftest - Build and run kernel selftest'
|
|
|
|
|
@echo ' Build, install, and boot kernel before'
|
|
|
|
|
@echo ' running kselftest on it'
|
|
|
|
|
@echo ' Run as root for full coverage'
|
|
|
|
|
@echo ' kselftest-all - Build kernel selftest'
|
|
|
|
|
@echo ' kselftest-install - Build and install kernel selftest'
|
|
|
|
|
@echo ' kselftest-clean - Remove all generated kselftest files'
|
|
|
|
|
@echo ' kselftest-merge - Merge all the config dependencies of'
|
|
|
|
|
@echo ' kselftest to existing .config.'
|
2014-08-07 19:07:46 +00:00
|
|
|
@echo ''
|
2021-07-03 14:42:57 +00:00
|
|
|
@echo 'Rust targets:'
|
|
|
|
|
@echo ' rustavailable - Checks whether the Rust toolchain is'
|
|
|
|
|
@echo ' available and, if not, explains why.'
|
|
|
|
|
@echo ' rustfmt - Reformat all the Rust code in the kernel'
|
|
|
|
|
@echo ' rustfmtcheck - Checks if all the Rust code in the kernel'
|
|
|
|
|
@echo ' is formatted, printing a diff otherwise.'
|
|
|
|
|
@echo ' rustdoc - Generate Rust documentation'
|
|
|
|
|
@echo ' (requires kernel .config)'
|
|
|
|
|
@echo ' rusttest - Runs the Rust tests'
|
|
|
|
|
@echo ' (requires kernel .config; downloads external repos)'
|
|
|
|
|
@echo ' rust-analyzer - Generate rust-project.json rust-analyzer support file'
|
|
|
|
|
@echo ' (requires kernel .config)'
|
|
|
|
|
@echo ' dir/file.[os] - Build specified target only'
|
|
|
|
|
@echo ' dir/file.rsi - Build macro expanded source, similar to C preprocessing.'
|
|
|
|
|
@echo ' Run with RUSTFMT=n to skip reformatting if needed.'
|
|
|
|
|
@echo ' The output is not intended to be compilable.'
|
|
|
|
|
@echo ' dir/file.ll - Build the LLVM assembly file'
|
|
|
|
|
@echo ''
|
2018-01-10 21:19:37 +00:00
|
|
|
@$(if $(dtstree), \
|
|
|
|
|
echo 'Devicetree:'; \
|
2024-04-05 22:56:03 +00:00
|
|
|
echo '* dtbs - Build device tree blobs for enabled boards'; \
|
|
|
|
|
echo ' dtbs_install - Install dtbs to $(INSTALL_DTBS_PATH)'; \
|
|
|
|
|
echo ' dt_binding_check - Validate device tree binding documents and examples'; \
|
2024-09-25 05:32:30 +00:00
|
|
|
echo ' dt_binding_schemas - Build processed device tree binding schemas'; \
|
2024-04-05 22:56:03 +00:00
|
|
|
echo ' dtbs_check - Validate device tree source files';\
|
2018-01-10 21:19:37 +00:00
|
|
|
echo '')
|
|
|
|
|
|
2017-05-08 22:55:08 +00:00
|
|
|
@echo 'Userspace tools targets:'
|
|
|
|
|
@echo ' use "make tools/help"'
|
|
|
|
|
@echo ' or "cd tools; make help"'
|
|
|
|
|
@echo ''
|
2005-04-16 22:20:36 +00:00
|
|
|
@echo 'Kernel packaging:'
|
2019-08-21 07:02:04 +00:00
|
|
|
@$(MAKE) -f $(srctree)/scripts/Makefile.package help
|
2005-04-16 22:20:36 +00:00
|
|
|
@echo ''
|
|
|
|
|
@echo 'Documentation targets:'
|
2017-05-14 14:50:01 +00:00
|
|
|
@$(MAKE) -f $(srctree)/Documentation/Makefile dochelp
|
2005-04-16 22:20:36 +00:00
|
|
|
@echo ''
|
2023-10-26 07:26:23 +00:00
|
|
|
@echo 'Architecture-specific targets ($(SRCARCH)):'
|
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>
2022-02-11 05:14:11 +00:00
|
|
|
@$(or $(archhelp),\
|
2023-10-26 07:26:23 +00:00
|
|
|
echo ' No architecture-specific help defined for $(SRCARCH)')
|
2005-04-16 22:20:36 +00:00
|
|
|
@echo ''
|
|
|
|
|
@$(if $(boards), \
|
|
|
|
|
$(foreach b, $(boards), \
|
2019-10-25 11:53:05 +00:00
|
|
|
printf " %-27s - Build for %s\\n" $(b) $(subst _defconfig,,$(b));) \
|
2005-04-16 22:20:36 +00:00
|
|
|
echo '')
|
2008-04-06 20:16:07 +00:00
|
|
|
@$(if $(board-dirs), \
|
|
|
|
|
$(foreach b, $(board-dirs), \
|
|
|
|
|
printf " %-16s - Show %s-specific targets\\n" help-$(b) $(b);) \
|
|
|
|
|
printf " %-16s - Show all of the above\\n" help-boards; \
|
|
|
|
|
echo '')
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2022-12-22 16:25:35 +00:00
|
|
|
@echo ' make V=n [targets] 1: verbose build'
|
2022-12-22 16:25:34 +00:00
|
|
|
@echo ' 2: give reason for rebuild of target'
|
|
|
|
|
@echo ' V=1 and V=2 can be combined with V=12'
|
2005-04-16 22:20:36 +00:00
|
|
|
@echo ' make O=dir [targets] Locate all output files in "dir", including .config'
|
2019-10-25 11:52:32 +00:00
|
|
|
@echo ' make C=1 [targets] Check re-compiled c source with $$CHECK'
|
|
|
|
|
@echo ' (sparse by default)'
|
2006-05-23 20:57:23 +00:00
|
|
|
@echo ' make C=2 [targets] Force check of all c source with $$CHECK'
|
2011-06-16 11:26:23 +00:00
|
|
|
@echo ' make RECORDMCOUNT_WARN=1 [targets] Warn about ignored mcount sections'
|
2024-01-20 08:32:55 +00:00
|
|
|
@echo ' make W=n [targets] Enable extra build checks, n=1,2,3,c,e where'
|
2011-04-27 20:15:27 +00:00
|
|
|
@echo ' 1: warnings which may be relevant and do not occur too often'
|
|
|
|
|
@echo ' 2: warnings which occur quite often but may still be relevant'
|
|
|
|
|
@echo ' 3: more obscure warnings, can most likely be ignored'
|
2023-11-23 09:05:40 +00:00
|
|
|
@echo ' c: extra checks in the configuration stage (Kconfig)'
|
2022-04-08 08:46:07 +00:00
|
|
|
@echo ' e: warnings are being treated as errors'
|
2011-04-29 12:45:31 +00:00
|
|
|
@echo ' Multiple levels can be combined with W=12 or W=123'
|
2022-12-20 01:32:33 +00:00
|
|
|
@$(if $(dtstree), \
|
|
|
|
|
echo ' make CHECK_DTBS=1 [targets] Check all generated dtb files against schema'; \
|
|
|
|
|
echo ' This can be applied both to "dtbs" and to individual "foo.dtb" targets' ; \
|
|
|
|
|
)
|
2005-04-16 22:20:36 +00:00
|
|
|
@echo ''
|
|
|
|
|
@echo 'Execute "make" or "make all" to build all targets marked with [*] '
|
|
|
|
|
@echo 'For further info see the ./README file'
|
|
|
|
|
|
|
|
|
|
|
2008-04-06 20:16:07 +00:00
|
|
|
help-board-dirs := $(addprefix help-,$(board-dirs))
|
|
|
|
|
|
|
|
|
|
help-boards: $(help-board-dirs)
|
|
|
|
|
|
2014-11-28 12:31:43 +00:00
|
|
|
boards-per-dir = $(sort $(notdir $(wildcard $(srctree)/arch/$(SRCARCH)/configs/$*/*_defconfig)))
|
2008-04-06 20:16:07 +00:00
|
|
|
|
|
|
|
|
$(help-board-dirs): help-%:
|
2023-10-26 07:26:23 +00:00
|
|
|
@echo 'Architecture-specific targets ($(SRCARCH) $*):'
|
2008-04-06 20:16:07 +00:00
|
|
|
@$(if $(boards-per-dir), \
|
|
|
|
|
$(foreach b, $(boards-per-dir), \
|
|
|
|
|
printf " %-24s - Build for %s\\n" $*/$(b) $(subst _defconfig,,$(b));) \
|
|
|
|
|
echo '')
|
|
|
|
|
|
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
# Documentation targets
|
|
|
|
|
# ---------------------------------------------------------------------------
|
2017-10-09 15:26:15 +00:00
|
|
|
DOC_TARGETS := xmldocs latexdocs pdfdocs htmldocs epubdocs cleandocs \
|
2022-11-16 19:02:09 +00:00
|
|
|
linkcheckdocs dochelp refcheckdocs texinfodocs infodocs
|
Documentation/sphinx: add basic working Sphinx configuration and build
Add basic configuration and makefile to build documentation from any
.rst files under Documentation using Sphinx. For starters, there's just
the placeholder index.rst.
At the top level Makefile, hook Sphinx documentation targets alongside
(but independent of) the DocBook toolchain, having both be run on the
various 'make *docs' targets.
All Sphinx processing is placed into Documentation/Makefile.sphinx. Both
that and the Documentation/DocBook/Makefile are now expected to handle
all the documentation targets, explicitly ignoring them if they're not
relevant for that particular toolchain. The changes to the existing
DocBook Makefile are kept minimal.
There is graceful handling of missing Sphinx and rst2pdf (which is
needed for pdf output) by checking for the tool and python module,
respectively, with informative messages to the user.
If the Read the Docs theme (sphinx_rtd_theme) is available, use it, but
otherwise gracefully fall back to the Sphinx default theme, with an
informative message to the user, and slightly less pretty HTML output.
Sphinx can now handle htmldocs, pdfdocs (if rst2pdf is available),
epubdocs and xmldocs targets. The output documents are written into per
output type subdirectories under Documentation/output.
Finally, you can pass options to sphinx-build using the SPHINXBUILD make
variable. For example, 'make SPHINXOPTS=-v htmldocs' for more verbose
output from Sphinx.
This is based on the original work by Jonathan Corbet, but he probably
wouldn't recognize this as his own anymore.
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2016-05-19 12:14:05 +00:00
|
|
|
PHONY += $(DOC_TARGETS)
|
2019-08-21 17:33:21 +00:00
|
|
|
$(DOC_TARGETS):
|
2017-05-14 14:50:01 +00:00
|
|
|
$(Q)$(MAKE) $(build)=Documentation $@
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2021-07-03 14:42:57 +00:00
|
|
|
|
|
|
|
|
# Rust targets
|
|
|
|
|
# ---------------------------------------------------------------------------
|
|
|
|
|
|
|
|
|
|
# "Is Rust available?" target
|
|
|
|
|
PHONY += rustavailable
|
|
|
|
|
rustavailable:
|
kbuild: mark `rustc` (and others) invocations as recursive
`rustc` (like Cargo) may take advantage of the jobserver at any time
(e.g. for backend parallelism, or eventually frontend too). In the kernel,
we call `rustc` with `-Ccodegen-units=1` (and `-Zthreads` is 1 so far),
so we do not expect parallelism. However, in the upcoming Rust 1.76.0, a
warning is emitted by `rustc` [1] when it cannot connect to the jobserver
it was passed (in many cases, but not all: compiling and `--print sysroot`
do, but `--version` does not). And given GNU Make always passes
the jobserver in the environment variable (even when a line is deemed
non-recursive), `rustc` will end up complaining about it (in particular
in Make 4.3 where there is only the simple pipe jobserver style).
One solution is to remove the jobserver from `MAKEFLAGS`. However, we
can mark the lines with calls to `rustc` (and Cargo) as recursive, which
looks simpler. This is being documented as a recommendation in `rustc`
[2] and allows us to be ready for the time we may use parallelism inside
`rustc` (potentially now, if a user passes `-Zthreads`). Thus do so.
Similarly, do the same for `rustdoc` and `cargo` calls.
Finally, there is one case that the solution does not cover, which is the
`$(shell ...)` call we have. Thus, for that one, set an empty `MAKEFLAGS`
environment variable.
Link: https://github.com/rust-lang/rust/issues/120515 [1]
Acked-by: Masahiro Yamada <masahiroy@kernel.org>
Link: https://github.com/rust-lang/rust/pull/121564 [2]
Link: https://lore.kernel.org/r/20240217002638.57373-1-ojeda@kernel.org
[ Reworded to add link to PR documenting the recommendation. ]
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
2024-02-17 00:26:37 +00:00
|
|
|
+$(Q)$(CONFIG_SHELL) $(srctree)/scripts/rust_is_available.sh && echo "Rust is available!"
|
2021-07-03 14:42:57 +00:00
|
|
|
|
|
|
|
|
# Documentation target
|
|
|
|
|
#
|
|
|
|
|
# Using the singular to avoid running afoul of `no-dot-config-targets`.
|
|
|
|
|
PHONY += rustdoc
|
|
|
|
|
rustdoc: prepare
|
|
|
|
|
$(Q)$(MAKE) $(build)=rust $@
|
|
|
|
|
|
|
|
|
|
# Testing target
|
|
|
|
|
PHONY += rusttest
|
|
|
|
|
rusttest: prepare
|
|
|
|
|
$(Q)$(MAKE) $(build)=rust $@
|
|
|
|
|
|
|
|
|
|
# Formatting targets
|
|
|
|
|
PHONY += rustfmt rustfmtcheck
|
|
|
|
|
|
|
|
|
|
rustfmt:
|
2024-10-24 17:09:22 +00:00
|
|
|
$(Q)find $(srctree) $(RCS_FIND_IGNORE) \
|
|
|
|
|
-type f -a -name '*.rs' -a ! -name '*generated*' -print \
|
2021-07-03 14:42:57 +00:00
|
|
|
| xargs $(RUSTFMT) $(rustfmt_flags)
|
|
|
|
|
|
|
|
|
|
rustfmtcheck: rustfmt_flags = --check
|
|
|
|
|
rustfmtcheck: rustfmt
|
|
|
|
|
|
2019-02-19 09:33:02 +00:00
|
|
|
# Misc
|
|
|
|
|
# ---------------------------------------------------------------------------
|
|
|
|
|
|
2022-12-29 07:43:10 +00:00
|
|
|
PHONY += misc-check
|
|
|
|
|
misc-check:
|
|
|
|
|
$(Q)$(srctree)/scripts/misc-check
|
|
|
|
|
|
|
|
|
|
all: misc-check
|
|
|
|
|
|
2019-02-19 09:33:02 +00:00
|
|
|
PHONY += scripts_gdb
|
2019-06-04 10:13:57 +00:00
|
|
|
scripts_gdb: prepare0
|
2019-02-19 09:33:04 +00:00
|
|
|
$(Q)$(MAKE) $(build)=scripts/gdb
|
2019-02-19 09:33:05 +00:00
|
|
|
$(Q)ln -fsn $(abspath $(srctree)/scripts/gdb/vmlinux-gdb.py)
|
2019-02-19 09:33:02 +00:00
|
|
|
|
|
|
|
|
ifdef CONFIG_GDB_SCRIPTS
|
|
|
|
|
all: scripts_gdb
|
|
|
|
|
endif
|
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
else # KBUILD_EXTMOD
|
|
|
|
|
|
2023-03-14 13:02:48 +00:00
|
|
|
filechk_kernel.release = echo $(KERNELRELEASE)
|
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
###
|
|
|
|
|
# External module support.
|
|
|
|
|
# When building external modules the kernel used as basis is considered
|
|
|
|
|
# read-only, and no consistency checks are made and the make
|
|
|
|
|
# system is not used on the basis kernel. If updates are required
|
2021-05-04 10:10:58 +00:00
|
|
|
# in the basis kernel ordinary make commands (without M=...) must be used.
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2020-09-08 20:55:57 +00:00
|
|
|
# We are always building only modules.
|
|
|
|
|
KBUILD_BUILTIN :=
|
2005-04-16 22:20:36 +00:00
|
|
|
KBUILD_MODULES := 1
|
|
|
|
|
|
2024-11-10 01:34:33 +00:00
|
|
|
build-dir := .
|
kbuild: wire up the build rule of compile_commands.json to Makefile
Currently, you need to manually run scripts/gen_compile_commands.py
to create compile_commands.json. It parses all the .*.cmd files found
under the specified directory.
If you rebuild the kernel over again without 'make clean',
.*.cmd files from older builds will create stale entries in
compile_commands.json.
This commit wires up the compile_commands.json rule to Makefile, and
makes it parse only the .*.cmd files involved in the current build.
Pass $(KBUILD_VMLINUX_OBJS), $(KBUILD_VMLINUX_LIBS), and modules.order
to the script. The objects or archives linked to vmlinux are listed in
$(KBUILD_VMLINUX_OBJS) or $(KBUILD_VMLINUX_LIBS). All the modules are
listed in modules.order.
You can create compile_commands.json from Make:
$ make -j$(nproc) CC=clang compile_commands.json
You can also build vmlinux, modules, and compile_commands.json all
together in a single command:
$ make -j$(nproc) CC=clang all compile_commands.json
It works for M= builds as well. In this case, compile_commands.json
is created in the top directory of the external module.
This is convenient, but it has a drawback; the coverage of the
compile_commands.json is reduced because only the objects linked to
vmlinux or modules are handled. For example, the following C files are
not included in the compile_commands.json:
- Decompressor source files (arch/*/boot/)
- VDSO source files
- C files used to generate intermediates (e.g. kernel/bounds.c)
- Standalone host programs
I think it is fine for most developers because our main interest is
the kernel-space code.
If you want to cover all the compiled C files, please build the kernel,
then run the script manually as you did before:
$ make clean # if you want to remove stale .cmd files [optional]
$ make -j$(nproc) CC=clang
$ scripts/gen_compile_commands.py
Here is a note for out-of-tree builds. 'make compile_commands.json'
works with O= option, but please notice compile_commands.json is
created in the object tree instead of the source tree.
Some people may want to have compile_commands.json in the source tree
because Clang Tools searches for it through all parent paths of the
first input source file.
However, you cannot do this for O= builds. Kbuild should never generate
any build artifact in the source tree when O= is given because the
source tree might be read-only. Any write attempt to the source tree
is monitored and the violation may be reported. See the commit log of
8ef14c2c41d9.
So, the only possible way is to create compile_commands.json in the
object tree, then specify '-p <build-path>' when you use clang-check,
clang-tidy, etc.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Acked-by: Nick Desaulniers <ndesaulniers@google.com>
2020-08-22 14:56:16 +00:00
|
|
|
|
2024-11-10 01:34:33 +00:00
|
|
|
clean-dirs := .
|
|
|
|
|
clean: private rm-files := Module.symvers modules.nsdeps compile_commands.json
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2021-08-01 02:53:46 +00:00
|
|
|
PHONY += prepare
|
|
|
|
|
# now expand this into a simple variable to reduce the cost of shell evaluations
|
|
|
|
|
prepare: CC_VERSION_TEXT := $(CC_VERSION_TEXT)
|
|
|
|
|
prepare:
|
kbuild: do not quote string values in include/config/auto.conf
The previous commit fixed up all shell scripts to not include
include/config/auto.conf.
Now that include/config/auto.conf is only included by Makefiles,
we can change it into a more Make-friendly form.
Previously, Kconfig output string values enclosed with double-quotes
(both in the .config and include/config/auto.conf):
CONFIG_X="foo bar"
Unlike shell, Make handles double-quotes (and single-quotes as well)
verbatim. We must rip them off when used.
There are some patterns:
[1] $(patsubst "%",%,$(CONFIG_X))
[2] $(CONFIG_X:"%"=%)
[3] $(subst ",,$(CONFIG_X))
[4] $(shell echo $(CONFIG_X))
These are not only ugly, but also fragile.
[1] and [2] do not work if the value contains spaces, like
CONFIG_X=" foo bar "
[3] does not work correctly if the value contains double-quotes like
CONFIG_X="foo\"bar"
[4] seems to work better, but has a cost of forking a process.
Anyway, quoted strings were always PITA for our Makefiles.
This commit changes Kconfig to stop quoting in include/config/auto.conf.
These are the string type symbols referenced in Makefiles or scripts:
ACPI_CUSTOM_DSDT_FILE
ARC_BUILTIN_DTB_NAME
ARC_TUNE_MCPU
BUILTIN_DTB_SOURCE
CC_IMPLICIT_FALLTHROUGH
CC_VERSION_TEXT
CFG80211_EXTRA_REGDB_KEYDIR
EXTRA_FIRMWARE
EXTRA_FIRMWARE_DIR
EXTRA_TARGETS
H8300_BUILTIN_DTB
INITRAMFS_SOURCE
LOCALVERSION
MODULE_SIG_HASH
MODULE_SIG_KEY
NDS32_BUILTIN_DTB
NIOS2_DTB_SOURCE
OPENRISC_BUILTIN_DTB
SOC_CANAAN_K210_DTB_SOURCE
SYSTEM_BLACKLIST_HASH_LIST
SYSTEM_REVOCATION_KEYS
SYSTEM_TRUSTED_KEYS
TARGET_CPU
UNUSED_KSYMS_WHITELIST
XILINX_MICROBLAZE0_FAMILY
XILINX_MICROBLAZE0_HW_VER
XTENSA_VARIANT_NAME
I checked them one by one, and fixed up the code where necessary.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2021-12-14 02:53:53 +00:00
|
|
|
@if [ "$(CC_VERSION_TEXT)" != "$(CONFIG_CC_VERSION_TEXT)" ]; then \
|
2021-08-01 02:53:46 +00:00
|
|
|
echo >&2 "warning: the compiler differs from the one used to build the kernel"; \
|
kbuild: do not quote string values in include/config/auto.conf
The previous commit fixed up all shell scripts to not include
include/config/auto.conf.
Now that include/config/auto.conf is only included by Makefiles,
we can change it into a more Make-friendly form.
Previously, Kconfig output string values enclosed with double-quotes
(both in the .config and include/config/auto.conf):
CONFIG_X="foo bar"
Unlike shell, Make handles double-quotes (and single-quotes as well)
verbatim. We must rip them off when used.
There are some patterns:
[1] $(patsubst "%",%,$(CONFIG_X))
[2] $(CONFIG_X:"%"=%)
[3] $(subst ",,$(CONFIG_X))
[4] $(shell echo $(CONFIG_X))
These are not only ugly, but also fragile.
[1] and [2] do not work if the value contains spaces, like
CONFIG_X=" foo bar "
[3] does not work correctly if the value contains double-quotes like
CONFIG_X="foo\"bar"
[4] seems to work better, but has a cost of forking a process.
Anyway, quoted strings were always PITA for our Makefiles.
This commit changes Kconfig to stop quoting in include/config/auto.conf.
These are the string type symbols referenced in Makefiles or scripts:
ACPI_CUSTOM_DSDT_FILE
ARC_BUILTIN_DTB_NAME
ARC_TUNE_MCPU
BUILTIN_DTB_SOURCE
CC_IMPLICIT_FALLTHROUGH
CC_VERSION_TEXT
CFG80211_EXTRA_REGDB_KEYDIR
EXTRA_FIRMWARE
EXTRA_FIRMWARE_DIR
EXTRA_TARGETS
H8300_BUILTIN_DTB
INITRAMFS_SOURCE
LOCALVERSION
MODULE_SIG_HASH
MODULE_SIG_KEY
NDS32_BUILTIN_DTB
NIOS2_DTB_SOURCE
OPENRISC_BUILTIN_DTB
SOC_CANAAN_K210_DTB_SOURCE
SYSTEM_BLACKLIST_HASH_LIST
SYSTEM_REVOCATION_KEYS
SYSTEM_TRUSTED_KEYS
TARGET_CPU
UNUSED_KSYMS_WHITELIST
XILINX_MICROBLAZE0_FAMILY
XILINX_MICROBLAZE0_HW_VER
XTENSA_VARIANT_NAME
I checked them one by one, and fixed up the code where necessary.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2021-12-14 02:53:53 +00:00
|
|
|
echo >&2 " The kernel was built by: $(CONFIG_CC_VERSION_TEXT)"; \
|
2021-08-01 02:53:46 +00:00
|
|
|
echo >&2 " You are using: $(CC_VERSION_TEXT)"; \
|
|
|
|
|
fi
|
|
|
|
|
|
2016-03-13 00:39:55 +00:00
|
|
|
PHONY += help
|
2005-04-16 22:20:36 +00:00
|
|
|
help:
|
|
|
|
|
@echo ' Building external modules.'
|
|
|
|
|
@echo ' Syntax: make -C path/to/kernel/src M=$$PWD target'
|
|
|
|
|
@echo ''
|
|
|
|
|
@echo ' modules - default target, build the module(s)'
|
|
|
|
|
@echo ' modules_install - install the module'
|
|
|
|
|
@echo ' clean - remove generated files in module directory only'
|
2023-04-11 09:17:15 +00:00
|
|
|
@echo ' rust-analyzer - generate rust-project.json rust-analyzer support file'
|
2005-04-16 22:20:36 +00:00
|
|
|
@echo ''
|
2006-01-25 06:13:18 +00:00
|
|
|
|
2023-08-23 11:50:46 +00:00
|
|
|
ifndef CONFIG_MODULES
|
|
|
|
|
modules modules_install: __external_modules_error
|
2023-06-15 11:17:43 +00:00
|
|
|
__external_modules_error:
|
|
|
|
|
@echo >&2 '***'
|
|
|
|
|
@echo >&2 '*** The present kernel disabled CONFIG_MODULES.'
|
|
|
|
|
@echo >&2 '*** You cannot build or install external modules.'
|
|
|
|
|
@echo >&2 '***'
|
|
|
|
|
@false
|
2023-08-23 11:50:46 +00:00
|
|
|
endif
|
2023-06-15 11:17:43 +00:00
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
endif # KBUILD_EXTMOD
|
|
|
|
|
|
2021-03-31 13:38:03 +00:00
|
|
|
# ---------------------------------------------------------------------------
|
|
|
|
|
# Modules
|
|
|
|
|
|
2023-08-23 11:50:48 +00:00
|
|
|
PHONY += modules modules_install modules_sign modules_prepare
|
2021-03-31 13:38:03 +00:00
|
|
|
|
2023-08-23 11:50:46 +00:00
|
|
|
modules_install:
|
2023-08-23 11:50:48 +00:00
|
|
|
$(Q)$(MAKE) -f $(srctree)/scripts/Makefile.modinst \
|
|
|
|
|
sign-only=$(if $(filter modules_install,$(MAKECMDGOALS)),,y)
|
|
|
|
|
|
|
|
|
|
ifeq ($(CONFIG_MODULE_SIG),y)
|
|
|
|
|
# modules_sign is a subset of modules_install.
|
|
|
|
|
# 'make modules_install modules_sign' is equivalent to 'make modules_install'.
|
|
|
|
|
modules_sign: modules_install
|
|
|
|
|
@:
|
|
|
|
|
else
|
|
|
|
|
modules_sign:
|
|
|
|
|
@echo >&2 '***'
|
|
|
|
|
@echo >&2 '*** CONFIG_MODULE_SIG is disabled. You cannot sign modules.'
|
|
|
|
|
@echo >&2 '***'
|
|
|
|
|
@false
|
|
|
|
|
endif
|
2021-03-31 13:38:03 +00:00
|
|
|
|
|
|
|
|
ifdef CONFIG_MODULES
|
|
|
|
|
|
2024-11-10 01:34:34 +00:00
|
|
|
modules.order: $(build-dir)
|
2022-09-24 18:19:10 +00:00
|
|
|
@:
|
|
|
|
|
|
2022-09-24 18:19:13 +00:00
|
|
|
# KBUILD_MODPOST_NOFINAL can be set to skip the final link of modules.
|
|
|
|
|
# This is solely useful to speed up test compiles.
|
|
|
|
|
modules: modpost
|
|
|
|
|
ifneq ($(KBUILD_MODPOST_NOFINAL),1)
|
|
|
|
|
$(Q)$(MAKE) -f $(srctree)/scripts/Makefile.modfinal
|
|
|
|
|
endif
|
2021-03-31 13:38:03 +00:00
|
|
|
|
2021-03-31 13:38:05 +00:00
|
|
|
PHONY += modules_check
|
2024-11-10 01:34:34 +00:00
|
|
|
modules_check: modules.order
|
2021-03-31 13:38:05 +00:00
|
|
|
$(Q)$(CONFIG_SHELL) $(srctree)/scripts/modules-check.sh $<
|
|
|
|
|
|
2021-03-31 13:38:03 +00:00
|
|
|
else # CONFIG_MODULES
|
|
|
|
|
|
2023-08-23 11:50:46 +00:00
|
|
|
modules:
|
2023-06-15 11:17:43 +00:00
|
|
|
@:
|
2021-03-31 13:38:03 +00:00
|
|
|
|
2022-08-28 02:39:50 +00:00
|
|
|
KBUILD_MODULES :=
|
|
|
|
|
|
2021-03-31 13:38:03 +00:00
|
|
|
endif # CONFIG_MODULES
|
|
|
|
|
|
2022-09-24 18:19:13 +00:00
|
|
|
PHONY += modpost
|
|
|
|
|
modpost: $(if $(single-build),, $(if $(KBUILD_BUILTIN), vmlinux.o)) \
|
|
|
|
|
$(if $(KBUILD_MODULES), modules_check)
|
|
|
|
|
$(Q)$(MAKE) -f $(srctree)/scripts/Makefile.modpost
|
|
|
|
|
|
2019-11-18 04:52:47 +00:00
|
|
|
# Single targets
|
|
|
|
|
# ---------------------------------------------------------------------------
|
|
|
|
|
# To build individual files in subdirectories, you can do like this:
|
|
|
|
|
#
|
|
|
|
|
# make foo/bar/baz.s
|
|
|
|
|
#
|
|
|
|
|
# The supported suffixes for single-target are listed in 'single-targets'
|
|
|
|
|
#
|
|
|
|
|
# To build only under specific subdirectories, you can do like this:
|
|
|
|
|
#
|
|
|
|
|
# make foo/bar/baz/
|
|
|
|
|
|
|
|
|
|
ifdef single-build
|
|
|
|
|
|
|
|
|
|
# .ko is special because modpost is needed
|
|
|
|
|
single-ko := $(sort $(filter %.ko, $(MAKECMDGOALS)))
|
2022-04-06 15:30:22 +00:00
|
|
|
single-no-ko := $(filter-out $(single-ko), $(MAKECMDGOALS)) \
|
|
|
|
|
$(foreach x, o mod, $(patsubst %.ko, %.$x, $(single-ko)))
|
2019-11-18 04:52:47 +00:00
|
|
|
|
2022-09-24 18:19:13 +00:00
|
|
|
$(single-ko): single_modules
|
2019-11-18 04:52:47 +00:00
|
|
|
@:
|
2022-09-24 18:19:10 +00:00
|
|
|
$(single-no-ko): $(build-dir)
|
2019-11-18 04:52:47 +00:00
|
|
|
@:
|
|
|
|
|
|
2024-11-10 01:34:34 +00:00
|
|
|
# Remove modules.order when done because it is not the real one.
|
2022-09-24 18:19:13 +00:00
|
|
|
PHONY += single_modules
|
|
|
|
|
single_modules: $(single-no-ko) modules_prepare
|
2024-11-10 01:34:34 +00:00
|
|
|
$(Q){ $(foreach m, $(single-ko), echo $(m:%.ko=%.o);) } > modules.order
|
2019-11-18 04:52:47 +00:00
|
|
|
$(Q)$(MAKE) -f $(srctree)/scripts/Makefile.modpost
|
2022-09-24 18:19:13 +00:00
|
|
|
ifneq ($(KBUILD_MODPOST_NOFINAL),1)
|
|
|
|
|
$(Q)$(MAKE) -f $(srctree)/scripts/Makefile.modfinal
|
2019-11-18 04:52:47 +00:00
|
|
|
endif
|
2024-11-10 01:34:34 +00:00
|
|
|
$(Q)rm -f modules.order
|
2019-11-18 04:52:47 +00:00
|
|
|
|
2022-09-24 18:19:10 +00:00
|
|
|
single-goals := $(addprefix $(build-dir)/, $(single-no-ko))
|
2019-11-18 04:52:47 +00:00
|
|
|
|
2022-10-14 20:18:11 +00:00
|
|
|
KBUILD_MODULES := 1
|
|
|
|
|
|
2020-05-22 01:59:59 +00:00
|
|
|
endif
|
|
|
|
|
|
2024-11-10 01:34:35 +00:00
|
|
|
prepare: outputmakefile
|
|
|
|
|
|
2019-08-10 15:53:04 +00:00
|
|
|
# Preset locale variables to speed up the build process. Limit locale
|
|
|
|
|
# tweaks to this spot to avoid wrong language settings when running
|
|
|
|
|
# make menuconfig etc.
|
|
|
|
|
# Error messages still appears in the original language
|
2022-09-24 18:19:10 +00:00
|
|
|
PHONY += $(build-dir)
|
|
|
|
|
$(build-dir): prepare
|
|
|
|
|
$(Q)$(MAKE) $(build)=$@ need-builtin=1 need-modorder=1 $(single-goals)
|
2019-08-10 15:53:04 +00:00
|
|
|
|
2019-08-10 15:53:05 +00:00
|
|
|
clean-dirs := $(addprefix _clean_, $(clean-dirs))
|
|
|
|
|
PHONY += $(clean-dirs) clean
|
|
|
|
|
$(clean-dirs):
|
|
|
|
|
$(Q)$(MAKE) $(clean)=$(patsubst _clean_%,%,$@)
|
|
|
|
|
|
2010-09-06 10:00:08 +00:00
|
|
|
clean: $(clean-dirs)
|
|
|
|
|
$(call cmd,rmfiles)
|
2024-11-10 01:34:33 +00:00
|
|
|
@find . $(RCS_FIND_IGNORE) \
|
2021-07-03 14:42:57 +00:00
|
|
|
\( -name '*.[aios]' -o -name '*.rsi' -o -name '*.ko' -o -name '.*.cmd' \
|
2018-09-06 18:26:07 +00:00
|
|
|
-o -name '*.ko.*' \
|
2022-11-14 20:59:39 +00:00
|
|
|
-o -name '*.dtb' -o -name '*.dtbo' \
|
|
|
|
|
-o -name '*.dtb.S' -o -name '*.dtbo.S' \
|
2024-01-09 12:07:34 +00:00
|
|
|
-o -name '*.dt.yaml' -o -name 'dtbs-list' \
|
2017-11-16 16:49:13 +00:00
|
|
|
-o -name '*.dwo' -o -name '*.lst' \
|
kbuild: implement CONFIG_TRIM_UNUSED_KSYMS without recursion
When CONFIG_TRIM_UNUSED_KSYMS is enabled, Kbuild recursively traverses
the directory tree to determine which EXPORT_SYMBOL to trim. If an
EXPORT_SYMBOL turns out to be unused by anyone, Kbuild begins the
second traverse, where some source files are recompiled with their
EXPORT_SYMBOL() tuned into a no-op.
Linus stated negative opinions about this slowness in commits:
- 5cf0fd591f2e ("Kbuild: disable TRIM_UNUSED_KSYMS option")
- a555bdd0c58c ("Kbuild: enable TRIM_UNUSED_KSYMS again, with some guarding")
We can do this better now. The final data structures of EXPORT_SYMBOL
are generated by the modpost stage, so modpost can selectively emit
KSYMTAB entries that are really used by modules.
Commit f73edc8951b2 ("kbuild: unify two modpost invocations") is another
ground-work to do this in a one-pass algorithm. With the list of modules,
modpost sets sym->used if it is used by a module. modpost emits KSYMTAB
only for symbols with sym->used==true.
BTW, Nicolas explained why the trimming was implemented with recursion:
https://lore.kernel.org/all/2o2rpn97-79nq-p7s2-nq5-8p83391473r@syhkavp.arg/
Actually, we never achieved that level of optimization where the chain
reaction of trimming comes into play because:
- CONFIG_LTO_CLANG cannot remove any unused symbols
- CONFIG_LD_DEAD_CODE_DATA_ELIMINATION is enabled only for vmlinux,
but not modules
If deeper trimming is required, we need to revisit this, but I guess
that is unlikely to happen.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
2023-06-11 15:50:57 +00:00
|
|
|
-o -name '*.su' -o -name '*.mod' \
|
2010-09-06 10:00:08 +00:00
|
|
|
-o -name '.*.d' -o -name '.*.tmp' -o -name '*.mod.c' \
|
2018-03-23 13:04:31 +00:00
|
|
|
-o -name '*.lex.c' -o -name '*.tab.[ch]' \
|
2018-03-23 13:04:37 +00:00
|
|
|
-o -name '*.asn1.[ch]' \
|
2010-09-06 10:00:08 +00:00
|
|
|
-o -name '*.symtypes' -o -name 'modules.order' \
|
2016-05-23 22:09:38 +00:00
|
|
|
-o -name '*.c.[012]*.*' \
|
2017-04-24 20:04:58 +00:00
|
|
|
-o -name '*.ll' \
|
2020-12-11 18:46:20 +00:00
|
|
|
-o -name '*.gcno' \
|
2024-08-18 08:37:29 +00:00
|
|
|
\) -type f -print \
|
2023-01-18 05:05:34 +00:00
|
|
|
-o -name '.tmp_*' -print \
|
|
|
|
|
| xargs rm -rf
|
2010-09-06 10:00:08 +00:00
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
# Generate tags for editors
|
|
|
|
|
# ---------------------------------------------------------------------------
|
2008-12-03 21:24:13 +00:00
|
|
|
quiet_cmd_tags = GEN $@
|
2019-08-25 13:28:37 +00:00
|
|
|
cmd_tags = $(BASH) $(srctree)/scripts/tags.sh $@
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2011-01-14 12:07:05 +00:00
|
|
|
tags TAGS cscope gtags: FORCE
|
2005-04-16 22:20:36 +00:00
|
|
|
$(call cmd,tags)
|
|
|
|
|
|
2024-06-28 00:43:56 +00:00
|
|
|
# Generate rust-project.json (a file that describes the structure of non-Cargo
|
|
|
|
|
# Rust projects) for rust-analyzer (an implementation of the Language Server
|
|
|
|
|
# Protocol).
|
2023-04-11 09:17:15 +00:00
|
|
|
PHONY += rust-analyzer
|
|
|
|
|
rust-analyzer:
|
2024-08-06 23:35:59 +00:00
|
|
|
+$(Q)$(CONFIG_SHELL) $(srctree)/scripts/rust_is_available.sh
|
2024-11-10 01:34:33 +00:00
|
|
|
ifdef KBUILD_EXTMOD
|
|
|
|
|
# FIXME: external modules must not descend into a sub-directory of the kernel
|
|
|
|
|
$(Q)$(MAKE) $(build)=$(objtree)/rust src=$(srctree)/rust $@
|
|
|
|
|
else
|
2023-04-11 09:17:15 +00:00
|
|
|
$(Q)$(MAKE) $(build)=rust $@
|
2024-11-10 01:34:33 +00:00
|
|
|
endif
|
2023-04-11 09:17:15 +00:00
|
|
|
|
2019-09-06 10:32:32 +00:00
|
|
|
# Script to generate missing namespace dependencies
|
|
|
|
|
# ---------------------------------------------------------------------------
|
|
|
|
|
|
|
|
|
|
PHONY += nsdeps
|
2019-10-29 12:38:06 +00:00
|
|
|
nsdeps: export KBUILD_NSDEPS=1
|
2019-09-06 10:32:32 +00:00
|
|
|
nsdeps: modules
|
2019-10-29 12:38:06 +00:00
|
|
|
$(Q)$(CONFIG_SHELL) $(srctree)/scripts/nsdeps
|
2019-09-06 10:32:32 +00:00
|
|
|
|
kbuild: wire up the build rule of compile_commands.json to Makefile
Currently, you need to manually run scripts/gen_compile_commands.py
to create compile_commands.json. It parses all the .*.cmd files found
under the specified directory.
If you rebuild the kernel over again without 'make clean',
.*.cmd files from older builds will create stale entries in
compile_commands.json.
This commit wires up the compile_commands.json rule to Makefile, and
makes it parse only the .*.cmd files involved in the current build.
Pass $(KBUILD_VMLINUX_OBJS), $(KBUILD_VMLINUX_LIBS), and modules.order
to the script. The objects or archives linked to vmlinux are listed in
$(KBUILD_VMLINUX_OBJS) or $(KBUILD_VMLINUX_LIBS). All the modules are
listed in modules.order.
You can create compile_commands.json from Make:
$ make -j$(nproc) CC=clang compile_commands.json
You can also build vmlinux, modules, and compile_commands.json all
together in a single command:
$ make -j$(nproc) CC=clang all compile_commands.json
It works for M= builds as well. In this case, compile_commands.json
is created in the top directory of the external module.
This is convenient, but it has a drawback; the coverage of the
compile_commands.json is reduced because only the objects linked to
vmlinux or modules are handled. For example, the following C files are
not included in the compile_commands.json:
- Decompressor source files (arch/*/boot/)
- VDSO source files
- C files used to generate intermediates (e.g. kernel/bounds.c)
- Standalone host programs
I think it is fine for most developers because our main interest is
the kernel-space code.
If you want to cover all the compiled C files, please build the kernel,
then run the script manually as you did before:
$ make clean # if you want to remove stale .cmd files [optional]
$ make -j$(nproc) CC=clang
$ scripts/gen_compile_commands.py
Here is a note for out-of-tree builds. 'make compile_commands.json'
works with O= option, but please notice compile_commands.json is
created in the object tree instead of the source tree.
Some people may want to have compile_commands.json in the source tree
because Clang Tools searches for it through all parent paths of the
first input source file.
However, you cannot do this for O= builds. Kbuild should never generate
any build artifact in the source tree when O= is given because the
source tree might be read-only. Any write attempt to the source tree
is monitored and the violation may be reported. See the commit log of
8ef14c2c41d9.
So, the only possible way is to create compile_commands.json in the
object tree, then specify '-p <build-path>' when you use clang-check,
clang-tidy, etc.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Acked-by: Nick Desaulniers <ndesaulniers@google.com>
2020-08-22 14:56:16 +00:00
|
|
|
# Clang Tooling
|
|
|
|
|
# ---------------------------------------------------------------------------
|
|
|
|
|
|
|
|
|
|
quiet_cmd_gen_compile_commands = GEN $@
|
|
|
|
|
cmd_gen_compile_commands = $(PYTHON3) $< -a $(AR) -o $@ $(filter-out $<, $(real-prereqs))
|
|
|
|
|
|
2024-11-10 01:34:34 +00:00
|
|
|
compile_commands.json: $(srctree)/scripts/clang-tools/gen_compile_commands.py \
|
2022-09-24 18:19:14 +00:00
|
|
|
$(if $(KBUILD_EXTMOD),, vmlinux.a $(KBUILD_VMLINUX_LIBS)) \
|
2024-11-10 01:34:34 +00:00
|
|
|
$(if $(CONFIG_MODULES), modules.order) FORCE
|
kbuild: wire up the build rule of compile_commands.json to Makefile
Currently, you need to manually run scripts/gen_compile_commands.py
to create compile_commands.json. It parses all the .*.cmd files found
under the specified directory.
If you rebuild the kernel over again without 'make clean',
.*.cmd files from older builds will create stale entries in
compile_commands.json.
This commit wires up the compile_commands.json rule to Makefile, and
makes it parse only the .*.cmd files involved in the current build.
Pass $(KBUILD_VMLINUX_OBJS), $(KBUILD_VMLINUX_LIBS), and modules.order
to the script. The objects or archives linked to vmlinux are listed in
$(KBUILD_VMLINUX_OBJS) or $(KBUILD_VMLINUX_LIBS). All the modules are
listed in modules.order.
You can create compile_commands.json from Make:
$ make -j$(nproc) CC=clang compile_commands.json
You can also build vmlinux, modules, and compile_commands.json all
together in a single command:
$ make -j$(nproc) CC=clang all compile_commands.json
It works for M= builds as well. In this case, compile_commands.json
is created in the top directory of the external module.
This is convenient, but it has a drawback; the coverage of the
compile_commands.json is reduced because only the objects linked to
vmlinux or modules are handled. For example, the following C files are
not included in the compile_commands.json:
- Decompressor source files (arch/*/boot/)
- VDSO source files
- C files used to generate intermediates (e.g. kernel/bounds.c)
- Standalone host programs
I think it is fine for most developers because our main interest is
the kernel-space code.
If you want to cover all the compiled C files, please build the kernel,
then run the script manually as you did before:
$ make clean # if you want to remove stale .cmd files [optional]
$ make -j$(nproc) CC=clang
$ scripts/gen_compile_commands.py
Here is a note for out-of-tree builds. 'make compile_commands.json'
works with O= option, but please notice compile_commands.json is
created in the object tree instead of the source tree.
Some people may want to have compile_commands.json in the source tree
because Clang Tools searches for it through all parent paths of the
first input source file.
However, you cannot do this for O= builds. Kbuild should never generate
any build artifact in the source tree when O= is given because the
source tree might be read-only. Any write attempt to the source tree
is monitored and the violation may be reported. See the commit log of
8ef14c2c41d9.
So, the only possible way is to create compile_commands.json in the
object tree, then specify '-p <build-path>' when you use clang-check,
clang-tidy, etc.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Acked-by: Nick Desaulniers <ndesaulniers@google.com>
2020-08-22 14:56:16 +00:00
|
|
|
$(call if_changed,gen_compile_commands)
|
|
|
|
|
|
2024-11-10 01:34:34 +00:00
|
|
|
targets += compile_commands.json
|
kbuild: wire up the build rule of compile_commands.json to Makefile
Currently, you need to manually run scripts/gen_compile_commands.py
to create compile_commands.json. It parses all the .*.cmd files found
under the specified directory.
If you rebuild the kernel over again without 'make clean',
.*.cmd files from older builds will create stale entries in
compile_commands.json.
This commit wires up the compile_commands.json rule to Makefile, and
makes it parse only the .*.cmd files involved in the current build.
Pass $(KBUILD_VMLINUX_OBJS), $(KBUILD_VMLINUX_LIBS), and modules.order
to the script. The objects or archives linked to vmlinux are listed in
$(KBUILD_VMLINUX_OBJS) or $(KBUILD_VMLINUX_LIBS). All the modules are
listed in modules.order.
You can create compile_commands.json from Make:
$ make -j$(nproc) CC=clang compile_commands.json
You can also build vmlinux, modules, and compile_commands.json all
together in a single command:
$ make -j$(nproc) CC=clang all compile_commands.json
It works for M= builds as well. In this case, compile_commands.json
is created in the top directory of the external module.
This is convenient, but it has a drawback; the coverage of the
compile_commands.json is reduced because only the objects linked to
vmlinux or modules are handled. For example, the following C files are
not included in the compile_commands.json:
- Decompressor source files (arch/*/boot/)
- VDSO source files
- C files used to generate intermediates (e.g. kernel/bounds.c)
- Standalone host programs
I think it is fine for most developers because our main interest is
the kernel-space code.
If you want to cover all the compiled C files, please build the kernel,
then run the script manually as you did before:
$ make clean # if you want to remove stale .cmd files [optional]
$ make -j$(nproc) CC=clang
$ scripts/gen_compile_commands.py
Here is a note for out-of-tree builds. 'make compile_commands.json'
works with O= option, but please notice compile_commands.json is
created in the object tree instead of the source tree.
Some people may want to have compile_commands.json in the source tree
because Clang Tools searches for it through all parent paths of the
first input source file.
However, you cannot do this for O= builds. Kbuild should never generate
any build artifact in the source tree when O= is given because the
source tree might be read-only. Any write attempt to the source tree
is monitored and the violation may be reported. See the commit log of
8ef14c2c41d9.
So, the only possible way is to create compile_commands.json in the
object tree, then specify '-p <build-path>' when you use clang-check,
clang-tidy, etc.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
Acked-by: Nick Desaulniers <ndesaulniers@google.com>
2020-08-22 14:56:16 +00:00
|
|
|
|
2020-08-22 14:56:18 +00:00
|
|
|
PHONY += clang-tidy clang-analyzer
|
|
|
|
|
|
|
|
|
|
ifdef CONFIG_CC_IS_CLANG
|
|
|
|
|
quiet_cmd_clang_tools = CHECK $<
|
|
|
|
|
cmd_clang_tools = $(PYTHON3) $(srctree)/scripts/clang-tools/run-clang-tools.py $@ $<
|
|
|
|
|
|
2024-11-10 01:34:34 +00:00
|
|
|
clang-tidy clang-analyzer: compile_commands.json
|
2020-08-22 14:56:18 +00:00
|
|
|
$(call cmd,clang_tools)
|
|
|
|
|
else
|
|
|
|
|
clang-tidy clang-analyzer:
|
|
|
|
|
@echo "$@ requires CC=clang" >&2
|
|
|
|
|
@false
|
|
|
|
|
endif
|
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
# Scripts to check various things for consistency
|
|
|
|
|
# ---------------------------------------------------------------------------
|
|
|
|
|
|
2024-10-30 17:16:34 +00:00
|
|
|
PHONY += includecheck versioncheck coccicheck
|
2011-04-26 21:15:01 +00:00
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
includecheck:
|
2011-04-26 21:18:29 +00:00
|
|
|
find $(srctree)/* $(RCS_FIND_IGNORE) \
|
2005-04-16 22:20:36 +00:00
|
|
|
-name '*.[hcS]' -type f -print | sort \
|
2007-11-05 10:51:44 +00:00
|
|
|
| xargs $(PERL) -w $(srctree)/scripts/checkincludes.pl
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
|
versioncheck:
|
2011-04-26 21:19:28 +00:00
|
|
|
find $(srctree)/* $(RCS_FIND_IGNORE) \
|
2005-04-16 22:20:36 +00:00
|
|
|
-name '*.[hcS]' -type f -print | sort \
|
2007-11-05 10:51:44 +00:00
|
|
|
| xargs $(PERL) -w $(srctree)/scripts/checkversion.pl
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2010-06-06 15:15:01 +00:00
|
|
|
coccicheck:
|
2019-08-25 13:28:37 +00:00
|
|
|
$(Q)$(BASH) $(srctree)/scripts/$@
|
2010-06-06 15:15:01 +00:00
|
|
|
|
2013-06-24 12:48:37 +00:00
|
|
|
PHONY += checkstack kernelrelease kernelversion image_name
|
2006-09-27 08:50:37 +00:00
|
|
|
|
2006-12-13 08:34:12 +00:00
|
|
|
# UML needs a little special treatment here. It wants to use the host
|
|
|
|
|
# toolchain, so needs $(SUBARCH) passed to checkstack.pl. Everyone
|
|
|
|
|
# else wants $(ARCH), including people doing cross-builds, which means
|
|
|
|
|
# that $(SUBARCH) doesn't work here.
|
|
|
|
|
ifeq ($(ARCH), um)
|
|
|
|
|
CHECKSTACK_ARCH := $(SUBARCH)
|
|
|
|
|
else
|
|
|
|
|
CHECKSTACK_ARCH := $(ARCH)
|
|
|
|
|
endif
|
2023-11-20 18:37:19 +00:00
|
|
|
MINSTACKSIZE ?= 100
|
2005-04-16 22:20:36 +00:00
|
|
|
checkstack:
|
|
|
|
|
$(OBJDUMP) -d vmlinux $$(find . -name '*.ko') | \
|
2023-11-20 18:37:19 +00:00
|
|
|
$(PERL) $(srctree)/scripts/checkstack.pl $(CHECKSTACK_ARCH) $(MINSTACKSIZE)
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2010-08-20 09:36:06 +00:00
|
|
|
kernelrelease:
|
2023-01-27 16:19:42 +00:00
|
|
|
@$(filechk_kernel.release)
|
2010-06-28 02:45:21 +00:00
|
|
|
|
2006-01-09 20:20:34 +00:00
|
|
|
kernelversion:
|
2006-01-16 11:12:12 +00:00
|
|
|
@echo $(KERNELVERSION)
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2013-06-24 12:48:37 +00:00
|
|
|
image_name:
|
|
|
|
|
@echo $(KBUILD_IMAGE)
|
|
|
|
|
|
2023-07-22 04:47:55 +00:00
|
|
|
PHONY += run-command
|
|
|
|
|
run-command:
|
|
|
|
|
$(Q)$(KBUILD_RUN_COMMAND)
|
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
quiet_cmd_rmfiles = $(if $(wildcard $(rm-files)),CLEAN $(wildcard $(rm-files)))
|
2020-05-04 08:08:07 +00:00
|
|
|
cmd_rmfiles = rm -rf $(rm-files)
|
2005-04-16 22:20:36 +00:00
|
|
|
|
kbuild: let fixdep directly write to .*.cmd files
Currently, fixdep writes dependencies to .*.tmp, which is renamed to
.*.cmd after everything succeeds. This is a very safe way to avoid
corrupted .*.cmd files. The if_changed_dep has carried this safety
mechanism since it was added in 2002.
If fixdep fails for some reasons or a user terminates the build while
fixdep is running, the incomplete output from the fixdep could be
troublesome.
This is my insight about some bad scenarios:
[1] If the compiler succeeds to generate *.o file, but fixdep fails
to write necessary dependencies to .*.cmd file, Make will miss
to rebuild the object when headers or CONFIG options are changed.
In this case, fixdep should not generate .*.cmd file at all so
that 'arg-check' will surely trigger the rebuild of the object.
[2] A partially constructed .*.cmd file may not be a syntactically
correct makefile. The next time Make runs, it would include it,
then fail to parse it. Once this happens, 'make clean' is be the
only way to fix it.
In fact, [1] is no longer a problem since commit 9c2af1c7377a ("kbuild:
add .DELETE_ON_ERROR special target"). Make deletes a target file on
any failure in its recipe. Because fixdep is a part of the recipe of
*.o target, if it fails, the *.o is deleted anyway. However, I am a
bit worried about the slight possibility of [2].
So, here is a solution. Let fixdep directly write to a .*.cmd file,
but allow makefiles to include it only when its corresponding target
exists.
This effectively reverts commit 2982c953570b ("kbuild: remove redundant
$(wildcard ...) for cmd_files calculation"), and commit 00d78ab2ba75
("kbuild: remove dead code in cmd_files calculation in top Makefile")
because now we must check the presence of targets.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2018-11-30 01:05:22 +00:00
|
|
|
# read saved command lines for existing targets
|
|
|
|
|
existing-targets := $(wildcard $(sort $(targets)))
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2019-02-22 07:40:08 +00:00
|
|
|
-include $(foreach f,$(existing-targets),$(dir $(f)).$(notdir $(f)).cmd)
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2020-02-29 16:09:58 +00:00
|
|
|
endif # config-build
|
2019-08-10 15:53:03 +00:00
|
|
|
endif # mixed-build
|
|
|
|
|
endif # need-sub-make
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2006-03-05 22:14:10 +00:00
|
|
|
PHONY += FORCE
|
2005-04-16 22:20:36 +00:00
|
|
|
FORCE:
|
2006-03-05 22:14:10 +00:00
|
|
|
|
2018-07-05 03:33:07 +00:00
|
|
|
# Declare the contents of the PHONY variable as phony. We keep that
|
2009-04-09 11:34:34 +00:00
|
|
|
# information in a variable so we can use it in if_changed and friends.
|
2006-03-05 22:14:10 +00:00
|
|
|
.PHONY: $(PHONY)
|