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 17:07:57 +03:00
# SPDX-License-Identifier: GPL-2.0
2019-01-07 04:08:20 +03:00
VERSION = 5
2019-09-30 20:35:40 +03:00
PATCHLEVEL = 4
2011-05-30 04:43:36 +04:00
SUBLEVEL = 0
2019-11-11 03:17:15 +03:00
EXTRAVERSION = -rc7
2019-10-27 20:19:19 +03:00
NAME = Kleptomaniac Octopus
2005-04-17 02:20:36 +04: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.
2017-10-04 06:56:05 +03:00
# That's our default target when none is given on the command line
PHONY := _all
_all :
2005-04-17 02:20:36 +04: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 17:25:04 +03:00
# unavoidable when linking the built-in.a targets which finally
2005-04-17 02:20:36 +04: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.
2019-03-26 07:02:19 +03:00
i f n e q ( $( sub_make_done ) , 1 )
2019-02-22 10:40:07 +03: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
u n export LC_ALL
LC_COLLATE = C
LC_NUMERIC = C
export LC_COLLATE LC_NUMERIC
# Avoid interference with shell env settings
u n export GREP_OPTIONS
2014-07-04 16:29:30 +04:00
# Beautify output
# ---------------------------------------------------------------------------
#
# Normally, we echo the whole command before executing it. By making
# that echo $($(quiet)$(cmd)), we now have the possibility to set
# $(quiet) to choose other forms of output instead, e.g.
#
# quiet_cmd_cc_o_c = Compiling $(RELDIR)/$@
# cmd_cc_o_c = $(CC) $(c_flags) -c -o $@ $<
#
# If $(quiet) is empty, the whole command will be printed.
# If it is set to "quiet_", only the short version will be printed.
# If it is set to "silent_", nothing will be printed at all, since
# the variable $(silent_cmd_cc_o_c) doesn't exist.
#
# A simple variant is to prefix commands with $(Q) - that's useful
# for commands that shall be hidden in non-verbose mode.
#
# $(Q)ln $@ :<
#
# If KBUILD_VERBOSE equals 0 then the above command will be hidden.
# If KBUILD_VERBOSE equals 1 then the above command is displayed.
#
2005-04-17 02:20:36 +04:00
# To put more focus on warnings, be less verbose as default
# Use 'make V=1' to see the full commands
2009-05-26 12:03:07 +04:00
i f e q ( "$(origin V)" , "command line" )
KBUILD_VERBOSE = $( V)
2005-04-17 02:20:36 +04:00
e n d i f
i f n d e f K B U I L D _ V E R B O S E
KBUILD_VERBOSE = 0
e n d i f
2014-07-04 16:29:30 +04:00
i f e q ( $( KBUILD_VERBOSE ) , 1 )
quiet =
Q =
e l s e
quiet = quiet_
Q = @
e n d i f
# If the user is running make -s (silent mode), suppress echoing of
# commands
2017-05-19 14:42:30 +03:00
i f n e q ( $( findstring s ,$ ( filter -out --%,$ ( MAKEFLAGS ) ) ) , )
2014-07-04 16:29:30 +04:00
quiet = silent_
e n d i f
export quiet Q KBUILD_VERBOSE
2019-03-30 15:04:14 +03: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-17 02:20:36 +04:00
# 1) O=
# Use "make O=dir/to/store/output/files/"
2006-06-25 02:07:55 +04:00
#
2005-04-17 02:20:36 +04:00
# 2) Set KBUILD_OUTPUT
2019-03-30 15:04:14 +03:00
# Set the environment variable KBUILD_OUTPUT to point to the output directory.
# export KBUILD_OUTPUT=dir/to/store/output/files/; make
2005-04-17 02:20:36 +04:00
#
# The O= assignment takes precedence over the KBUILD_OUTPUT environment
# variable.
2019-03-30 15:04:14 +03:00
# Do we want to change the working directory?
2009-05-26 12:03:07 +04:00
i f e q ( "$(origin O)" , "command line" )
KBUILD_OUTPUT := $( O)
2005-04-17 02:20:36 +04:00
e n d i f
2019-03-30 15:04:14 +03:00
i f n e q ( $( KBUILD_OUTPUT ) , )
# Make's built-in functions such as $(abspath ...), $(realpath ...) cannot
# expand a shell special character '~'. We use a somewhat tedious way here.
abs_objtree := $( shell mkdir -p $( KBUILD_OUTPUT) && cd $( KBUILD_OUTPUT) && pwd )
$( if $ ( abs_objtree ) ,, \
$( error failed to create output directory " $( KBUILD_OUTPUT) " ) )
# $(realpath ...) resolves symlinks
abs_objtree := $( realpath $( abs_objtree) )
e l s e
abs_objtree := $( CURDIR)
e n d i f # ifneq ($(KBUILD_OUTPUT),)
i f e q ( $( abs_objtree ) , $( CURDIR ) )
# Suppress "Entering directory ..." unless we are changing the work directory.
MAKEFLAGS += --no-print-directory
e l s e
need-sub-make := 1
2016-04-02 22:38:53 +03:00
e n d i f
2019-03-30 15:04:14 +03:00
abs_srctree := $( realpath $( dir $( lastword $( MAKEFILE_LIST) ) ) )
2005-04-17 02:20:36 +04:00
2019-03-30 15:04:14 +03:00
ifneq ($(words $(subst : , , $( abs_srctree ) )), 1)
$( error source directory cannot contain spaces or colons )
e n d i f
2005-04-17 02:20:36 +04:00
2019-03-30 15:04:14 +03:00
i f n e q ( $( abs_srctree ) , $( abs_objtree ) )
2018-09-14 09:33:23 +03:00
# Look for make include files relative to root of kernel src
#
# This does not become effective immediately because MAKEFLAGS is re-parsed
2019-03-30 15:04:14 +03:00
# once after the Makefile is read. We need to invoke sub-make.
MAKEFLAGS += --include-dir= $( abs_srctree)
2019-03-19 07:02:36 +03:00
need-sub-make := 1
2019-03-30 15:04:14 +03:00
e n d i f
2019-02-22 10:40:07 +03:00
2019-03-19 07:02:36 +03:00
i f n e q ( $( filter 3.%,$ ( MAKE_VERSION ) ) , )
# 'MAKEFLAGS += -rR' does not immediately become effective for GNU Make 3.x
# We need to invoke sub-make to avoid implicit rules in the top Makefile.
need-sub-make := 1
# Cancel implicit rules for this Makefile.
$(lastword $(MAKEFILE_LIST)) : ;
e n d i f
2019-03-30 15:04:14 +03:00
export abs_srctree abs_objtree
2019-03-26 07:02:19 +03:00
export sub_make_done := 1
2019-03-19 07:02:36 +03:00
i f e q ( $( need -sub -make ) , 1 )
2007-09-22 03:09:02 +04:00
PHONY += $( MAKECMDGOALS) sub-make
2019-03-26 09:32:16 +03:00
$(filter-out _all sub-make $(lastword $(MAKEFILE_LIST)), $(MAKECMDGOALS)) _all : sub -make
2012-10-15 16:49:12 +04:00
@:
2007-09-22 03:09:02 +04:00
2017-06-30 05:45:43 +03:00
# Invoke a second make in the output directory, passing relevant variables
2016-03-13 03:13:55 +03:00
sub-make :
2019-03-30 15:04:14 +03:00
$( Q) $( MAKE) -C $( abs_objtree) -f $( abs_srctree) /Makefile $( MAKECMDGOALS)
2005-04-17 02:20:36 +04:00
2019-03-19 07:02:36 +03:00
e n d i f # need-sub-make
2019-03-26 07:02:19 +03:00
e n d i f # sub_make_done
2019-03-19 07:02:36 +03:00
2005-04-17 02:20:36 +04:00
# We process the rest of the Makefile if this is the final invocation of make
2019-03-19 07:02:36 +03:00
i f e q ( $( need -sub -make ) , )
2005-04-17 02:20:36 +04:00
2014-09-09 15:02:22 +04:00
# Do not print "Entering directory ...",
# but we want to display it when entering to the output directory
# so that IDEs/editors are able to understand relative filenames.
MAKEFLAGS += --no-print-directory
2014-09-09 15:02:24 +04: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.
#
2017-03-24 12:03:17 +03:00
# See the file "Documentation/dev-tools/sparse.rst" for more details,
# including where to get the "sparse" utility.
2014-09-09 15:02:24 +04:00
i f e q ( "$(origin C)" , "command line" )
KBUILD_CHECKSRC = $( C)
e n d i f
i f n d e f K B U I L D _ C H E C K S R C
KBUILD_CHECKSRC = 0
e n d i f
2019-09-21 10:05:41 +03: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.
2014-09-09 15:02:24 +04:00
i f e q ( "$(origin M)" , "command line" )
KBUILD_EXTMOD := $( M)
e n d i f
2019-07-06 06:07:12 +03:00
export KBUILD_CHECKSRC KBUILD_EXTMOD
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 18:19:18 +03:00
extmod-prefix = $( if $( KBUILD_EXTMOD) ,$( KBUILD_EXTMOD) /)
2019-03-30 15:04:14 +03:00
i f e q ( $( abs_srctree ) , $( abs_objtree ) )
2014-04-26 01:25:18 +04:00
# building in the source tree
srctree := .
2019-07-06 06:07:12 +03:00
building_out_of_srctree :=
2014-04-26 01:25:18 +04:00
e l s e
2019-03-30 15:04:14 +03:00
ifeq ( $( abs_srctree) /,$( dir $( abs_objtree) ) )
2014-04-26 01:25:18 +04:00
# building in a subdirectory of the source tree
srctree := ..
else
2019-03-30 15:04:14 +03:00
srctree := $( abs_srctree)
2014-04-26 01:25:18 +04:00
endif
2019-07-06 06:07:12 +03:00
building_out_of_srctree := 1
2014-04-26 01:25:18 +04:00
e n d i f
2017-10-04 06:56:06 +03:00
2019-07-06 06:07:13 +03:00
i f n e q ( $( KBUILD_ABS_SRCTREE ) , )
srctree := $( abs_srctree)
e n d i f
2017-10-04 06:56:06 +03:00
2014-04-25 19:29:45 +04:00
objtree := .
2019-02-22 10:40:09 +03:00
VPATH := $( srctree)
2005-04-17 02:20:36 +04:00
2019-07-06 06:07:12 +03:00
export building_out_of_srctree srctree objtree VPATH
2005-04-17 02:20:36 +04:00
2017-10-04 06:56:06 +03: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
old_version_h := include/linux/version.h
2018-02-11 11:40:29 +03:00
clean-targets := %clean mrproper cleandocs
no-dot-config-targets := $( clean-targets) \
2017-10-04 06:56:06 +03: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 13:14:02 +03:00
$( version_h) headers headers_% archheaders archscripts \
2018-08-04 07:47:02 +03:00
%asm-generic kernelversion %src-pkg
2018-07-20 10:46:35 +03:00
no-sync-config-targets := $( no-dot-config-targets) install %install \
kernelrelease
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 18:19:18 +03:00
single-targets := %.a %.i %.ko %.lds %.ll %.lst %.mod %.o %.s %.symtypes %/
2017-10-04 06:56:06 +03:00
2019-08-10 18:53:03 +03: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 18:19:18 +03:00
single-build :=
2017-10-04 06:56:06 +03:00
i f n e q ( $( filter $ ( no -dot -config -targets ) , $ ( MAKECMDGOALS ) ) , )
ifeq ( $( filter-out $( no-dot-config-targets) , $( MAKECMDGOALS) ) ,)
2019-08-10 18:53:03 +03:00
need-config :=
2017-10-04 06:56:06 +03:00
endif
e n d i f
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 10:46:34 +03:00
i f n e q ( $( filter $ ( no -sync -config -targets ) , $ ( MAKECMDGOALS ) ) , )
ifeq ( $( filter-out $( no-sync-config-targets) , $( MAKECMDGOALS) ) ,)
2019-08-10 18:53:03 +03: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 10:46:34 +03:00
endif
e n d i f
i f n e q ( $( KBUILD_EXTMOD ) , )
2019-08-10 18:53:03 +03: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 10:46:34 +03:00
e n d i f
2017-10-04 06:56:06 +03:00
i f e q ( $( KBUILD_EXTMOD ) , )
ifneq ( $( filter config %config,$( MAKECMDGOALS) ) ,)
2019-08-10 18:53:03 +03:00
config-build := 1
2017-10-04 06:56:06 +03:00
ifneq ( $( words $( MAKECMDGOALS) ) ,1)
2019-08-10 18:53:03 +03:00
mixed-build := 1
2017-10-04 06:56:06 +03:00
endif
endif
e n d i f
2018-02-11 11:40:29 +03: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 18:19:18 +03:00
# We cannot build single targets and the others at the same time
i f n e q ( $( filter $ ( single -targets ) , $ ( MAKECMDGOALS ) ) , )
single-build := 1
ifneq ( $( filter-out $( single-targets) , $( MAKECMDGOALS) ) ,)
mixed-build := 1
endif
e n d i f
2018-02-11 11:40:29 +03:00
# For "make -j clean all", "make -j mrproper defconfig all", etc.
i f n e q ( $( filter $ ( clean -targets ) ,$ ( MAKECMDGOALS ) ) , )
ifneq ( $( filter-out $( clean-targets) ,$( MAKECMDGOALS) ) ,)
2019-08-10 18:53:03 +03:00
mixed-build := 1
2018-02-11 11:40:29 +03:00
endif
e n d i f
2017-10-04 06:56:06 +03:00
# install and modules_install need also be processed one by one
i f n e q ( $( filter install ,$ ( MAKECMDGOALS ) ) , )
ifneq ( $( filter modules_install,$( MAKECMDGOALS) ) ,)
2019-08-10 18:53:03 +03:00
mixed-build := 1
2017-10-04 06:56:06 +03:00
endif
e n d i f
2019-08-10 18:53:03 +03:00
i f d e f m i x e d - b u i l d
2017-10-04 06:56:06 +03:00
# ===========================================================================
# We're called with mixed targets (*config and build targets).
# Handle them one by one.
PHONY += $( MAKECMDGOALS) __build_one_by_one
$(filter-out __build_one_by_one, $(MAKECMDGOALS)) : __build_one_by_one
@:
__build_one_by_one :
$( Q) set -e; \
for i in $( MAKECMDGOALS) ; do \
$( MAKE) -f $( srctree) /Makefile $$ i; \
done
2019-08-10 18:53:03 +03:00
e l s e # !mixed-build
2017-10-04 06:56:06 +03:00
i n c l u d e s c r i p t s / K b u i l d . i n c l u d e
# Read KERNELRELEASE from include/config/kernel.release (if it exists)
KERNELRELEASE = $( shell cat include/config/kernel.release 2> /dev/null)
KERNELVERSION = $( VERSION) $( if $( PATCHLEVEL) ,.$( PATCHLEVEL) $( if $( SUBLEVEL) ,.$( SUBLEVEL) ) ) $( EXTRAVERSION)
export VERSION PATCHLEVEL SUBLEVEL KERNELRELEASE KERNELVERSION
2018-09-04 13:47:21 +03:00
i n c l u d e s c r i p t s / s u b a r c h . i n c l u d e
2005-04-17 02:20:36 +04: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:
# make ARCH=ia64
# 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
# make CROSS_COMPILE=ia64-linux-
# 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-12 01:22:58 +04:00
ARCH ?= $( SUBARCH)
2005-04-17 02:20:36 +04:00
# Architecture as present in compile.h
2007-10-11 13:11:36 +04:00
UTS_MACHINE := $( ARCH)
SRCARCH := $( ARCH)
2005-04-17 02:20:36 +04:00
2007-11-12 22:14:19 +03:00
# Additional ARCH settings for x86
i f e q ( $( ARCH ) , i 3 8 6 )
SRCARCH := x86
e n d i f
i f e q ( $( ARCH ) , x 8 6 _ 6 4 )
SRCARCH := x86
e n d i f
2007-10-25 21:42:04 +04:00
2008-12-03 10:17:12 +03:00
# Additional ARCH settings for sparc
2010-10-25 09:48:23 +04:00
i f e q ( $( ARCH ) , s p a r c 3 2 )
SRCARCH := sparc
e n d i f
2008-07-28 01:00:59 +04:00
i f e q ( $( ARCH ) , s p a r c 6 4 )
2008-12-03 10:17:12 +03:00
SRCARCH := sparc
2008-07-28 01:00:59 +04:00
e n d i f
2008-06-21 02:24:17 +04:00
2009-04-11 03:39:27 +04:00
# Additional ARCH settings for sh
i f e q ( $( ARCH ) , s h 6 4 )
SRCARCH := sh
e n d i f
2006-06-09 09:12:51 +04:00
KCONFIG_CONFIG ?= .config
2010-12-14 19:39:44 +03:00
export KCONFIG_CONFIG
2006-06-09 09:12:51 +04:00
2005-04-17 02:20:36 +04:00
# SHELL used by kbuild
2019-08-25 16:28:37 +03:00
CONFIG_SHELL := sh
2005-04-17 02:20:36 +04:00
2018-07-12 13:38:36 +03: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 21:02:36 +03:00
2006-06-25 02:07:55 +04:00
HOSTCC = gcc
HOSTCXX = g++
2018-07-10 03:45:58 +03:00
KBUILD_HOSTCFLAGS := -Wall -Wmissing-prototypes -Wstrict-prototypes -O2 \
2018-07-10 03:46:02 +03:00
-fomit-frame-pointer -std= gnu89 $( HOST_LFS_CFLAGS) \
$( HOSTCFLAGS)
KBUILD_HOSTCXXFLAGS := -O2 $( HOST_LFS_CFLAGS) $( HOSTCXXFLAGS)
KBUILD_HOSTLDFLAGS := $( HOST_LFS_LDFLAGS) $( HOSTLDFLAGS)
KBUILD_HOSTLDLIBS := $( HOST_LFS_LIBS) $( HOSTLDLIBS)
2005-04-17 02:20:36 +04:00
# Make variables (CC, etc...)
AS = $( CROSS_COMPILE) as
LD = $( CROSS_COMPILE) ld
CC = $( CROSS_COMPILE) gcc
CPP = $( CC) -E
AR = $( CROSS_COMPILE) ar
NM = $( CROSS_COMPILE) nm
STRIP = $( CROSS_COMPILE) strip
OBJCOPY = $( CROSS_COMPILE) objcopy
OBJDUMP = $( CROSS_COMPILE) objdump
2019-01-21 15:54:39 +03:00
OBJSIZE = $( CROSS_COMPILE) size
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 19:49:50 +03:00
PAHOLE = pahole
2017-12-09 19:02:28 +03:00
LEX = flex
YACC = bison
2005-04-17 02:20:36 +04:00
AWK = awk
2009-07-20 23:37:11 +04:00
INSTALLKERNEL := installkernel
2005-04-17 02:20:36 +04:00
DEPMOD = /sbin/depmod
PERL = perl
2014-07-18 08:40:11 +04:00
PYTHON = python
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 12:12:02 +03:00
PYTHON2 = python2
PYTHON3 = python3
2005-04-17 02:20:36 +04:00
CHECK = sparse
2019-08-25 16:28:37 +03:00
BASH = bash
2005-04-17 02:20:36 +04:00
2008-12-28 00:38:44 +03:00
CHECKFLAGS := -D__linux__ -Dlinux -D__STDC__ -Dunix -D__unix__ \
2018-02-16 00:07:50 +03:00
-Wbitwise -Wno-return-void -Wno-unknown-attribute $( CF)
2019-03-15 02:41:59 +03: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 19:33:09 +04:00
CFLAGS_MODULE =
AFLAGS_MODULE =
LDFLAGS_MODULE =
2005-04-17 02:20:36 +04:00
CFLAGS_KERNEL =
AFLAGS_KERNEL =
2016-06-07 12:57:02 +03:00
LDFLAGS_vmlinux =
2005-04-17 02:20:36 +04:00
2012-10-02 21:01:26 +04:00
# Use USERINCLUDE when you must reference the UAPI directories only.
USERINCLUDE := \
2017-10-04 06:56:04 +03:00
-I$( srctree) /arch/$( SRCARCH) /include/uapi \
-I$( objtree) /arch/$( SRCARCH) /include/generated/uapi \
2012-10-02 21:01:26 +04:00
-I$( srctree) /include/uapi \
2016-06-15 18:45:45 +03:00
-I$( objtree) /include/generated/uapi \
2012-10-02 21:01:26 +04:00
-include $( srctree) /include/linux/kconfig.h
2005-04-17 02:20:36 +04:00
# Use LINUXINCLUDE when you must reference the include/ directory.
# Needed to be compatible with the O= option
2012-10-02 21:01:26 +04:00
LINUXINCLUDE := \
2017-10-04 06:56:04 +03:00
-I$( srctree) /arch/$( SRCARCH) /include \
-I$( objtree) /arch/$( SRCARCH) /include/generated \
2019-07-06 06:07:12 +03:00
$( if $( building_out_of_srctree) ,-I$( srctree) /include) \
2017-06-06 10:15:28 +03:00
-I$( objtree) /include \
$( USERINCLUDE)
2005-04-17 02:20:36 +04:00
2018-12-14 11:05:37 +03:00
KBUILD_AFLAGS := -D__ASSEMBLY__ -fno-PIE
2018-12-14 11:05:38 +03:00
KBUILD_CFLAGS := -Wall -Wundef -Werror= strict-prototypes -Wno-trigraphs \
2018-12-14 11:05:37 +03:00
-fno-strict-aliasing -fno-common -fshort-wchar -fno-PIE \
2019-03-04 15:55:20 +03:00
-Werror= implicit-function-declaration -Werror= implicit-int \
2014-10-20 13:23:12 +04:00
-Wno-format-security \
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 12:22:25 +03:00
-std= gnu89
KBUILD_CPPFLAGS := -D__KERNEL__
2010-07-28 21:11:27 +04:00
KBUILD_AFLAGS_KERNEL :=
KBUILD_CFLAGS_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 19:33:09 +04:00
KBUILD_AFLAGS_MODULE := -DMODULE
KBUILD_CFLAGS_MODULE := -DMODULE
2019-08-14 19:06:22 +03:00
KBUILD_LDFLAGS_MODULE :=
export KBUILD_LDS_MODULE := $( srctree) /scripts/module-common.lds
2018-08-24 02:20:39 +03:00
KBUILD_LDFLAGS :=
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 12:22:25 +03:00
GCC_PLUGINS_CFLAGS :=
2019-07-29 12:15:17 +03:00
CLANG_FLAGS :=
2005-04-17 02:20:36 +04:00
2019-08-25 16:28:37 +03:00
export ARCH SRCARCH CONFIG_SHELL BASH HOSTCC KBUILD_HOSTCFLAGS CROSS_COMPILE AS LD CC
2019-01-21 15:54:39 +03:00
export CPP AR NM STRIP OBJCOPY OBJDUMP OBJSIZE PAHOLE LEX YACC AWK INSTALLKERNEL
export PERL PYTHON PYTHON2 PYTHON3 CHECK CHECKFLAGS MAKE UTS_MACHINE HOSTCXX
export KBUILD_HOSTCXXFLAGS KBUILD_HOSTLDFLAGS KBUILD_HOSTLDLIBS LDFLAGS_MODULE
2005-04-17 02:20:36 +04:00
2018-08-24 02:20:39 +03:00
export KBUILD_CPPFLAGS NOSTDINC_FLAGS LINUXINCLUDE OBJCOPYFLAGS KBUILD_LDFLAGS
2018-02-07 02:36:00 +03:00
export KBUILD_CFLAGS CFLAGS_KERNEL CFLAGS_MODULE
export CFLAGS_KASAN CFLAGS_KASAN_NOSANITIZE CFLAGS_UBSAN
2007-10-15 23:59:31 +04:00
export KBUILD_AFLAGS AFLAGS_KERNEL AFLAGS_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 19:33:09 +04:00
export KBUILD_AFLAGS_MODULE KBUILD_CFLAGS_MODULE KBUILD_LDFLAGS_MODULE
2010-07-28 21:11:27 +04:00
export KBUILD_AFLAGS_KERNEL KBUILD_CFLAGS_KERNEL
2005-04-17 02:20:36 +04:00
# Files to ignore in find ... statements
2014-02-06 16:51:42 +04: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
2012-02-17 01:49:15 +04:00
export RCS_TAR_IGNORE := --exclude SCCS --exclude BitKeeper --exclude .svn \
--exclude CVS --exclude .pc --exclude .hg --exclude .git
2005-04-17 02:20:36 +04:00
# ===========================================================================
# Rules shared between *config targets and build targets
2017-08-02 05:31:06 +03:00
# Basic helpers built in scripts/basic/
2006-03-06 01:14:10 +03:00
PHONY += scripts_basic
2005-04-17 02:20:36 +04:00
scripts_basic :
$( Q) $( MAKE) $( build) = scripts/basic
2009-11-17 18:48:25 +03:00
$( Q) rm -f .tmp_quiet_recordmcount
2005-04-17 02:20:36 +04:00
2006-03-06 01:14:10 +03:00
PHONY += outputmakefile
2019-08-22 07:46:11 +03:00
# Before starting out-of-tree build, make sure the source tree is clean.
2006-05-02 14:33:20 +04: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 11:48:40 +03:00
# At the same time when output Makefile generated, generate .gitignore to
# ignore whole output directory
2005-04-17 02:20:36 +04:00
outputmakefile :
2019-07-06 06:07:12 +03:00
i f d e f b u i l d i n g _ o u t _ o f _ s r c t r e e
2019-08-22 07:46:11 +03:00
$( Q) if [ -f $( srctree) /.config -o \
-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
2009-01-10 06:56:13 +03:00
$( Q) ln -fsn $( srctree) source
2018-09-18 11:45:53 +03:00
$( Q) $( CONFIG_SHELL) $( srctree) /scripts/mkmakefile $( srctree)
2019-03-26 07:26:58 +03:00
$( Q) test -e .gitignore || \
{ echo "# this is build directory, ignore it" ; echo "*" ; } > .gitignore
2006-05-02 14:33:20 +04:00
e n d i f
2005-04-17 02:20:36 +04:00
2018-10-30 16:26:34 +03:00
i f n e q ( $( shell $ ( CC ) --version 2>&1 | head -n 1 | grep clang ) , )
2017-11-07 22:46:13 +03:00
i f n e q ( $( CROSS_COMPILE ) , )
2019-07-29 12:15:17 +03:00
CLANG_FLAGS += --target= $( notdir $( CROSS_COMPILE:%-= %) )
2019-02-11 22:30:04 +03:00
GCC_TOOLCHAIN_DIR := $( dir $( shell which $( CROSS_COMPILE) elfedit) )
2018-11-06 06:04:55 +03:00
CLANG_FLAGS += --prefix= $( GCC_TOOLCHAIN_DIR)
2018-09-18 05:31:57 +03:00
GCC_TOOLCHAIN := $( realpath $( GCC_TOOLCHAIN_DIR) /..)
2017-11-07 22:46:13 +03:00
e n d i f
i f n e q ( $( GCC_TOOLCHAIN ) , )
2018-11-06 06:04:55 +03:00
CLANG_FLAGS += --gcc-toolchain= $( GCC_TOOLCHAIN)
2017-11-07 22:46:13 +03:00
e n d i f
2019-06-27 22:14:48 +03:00
i f e q ( $( shell $ ( AS ) --version 2>&1 | head -n 1 | grep clang ) , )
2018-11-06 06:04:55 +03:00
CLANG_FLAGS += -no-integrated-as
2019-06-27 22:14:48 +03:00
e n d i f
kbuild: Add -Werror=unknown-warning-option to CLANG_FLAGS
In commit ebcc5928c5d9 ("arm64: Silence gcc warnings about arch ABI
drift"), the arm64 Makefile added -Wno-psabi to KBUILD_CFLAGS, which is
a GCC only option so clang rightfully complains:
warning: unknown warning option '-Wno-psabi' [-Wunknown-warning-option]
https://clang.llvm.org/docs/DiagnosticsReference.html#wunknown-warning-option
However, by default, this is merely a warning so the build happily goes
on with a slew of these warnings in the process.
Commit c3f0d0bc5b01 ("kbuild, LLVMLinux: Add -Werror to cc-option to
support clang") worked around this behavior in cc-option by adding
-Werror so that unknown flags cause an error. However, this all happens
silently and when an unknown flag is added to the build unconditionally
like -Wno-psabi, cc-option will always fail because there is always an
unknown flag in the list of flags. This manifested as link time failures
in the arm64 libstub because -fno-stack-protector didn't get added to
KBUILD_CFLAGS.
To avoid these weird cryptic failures in the future, make clang behave
like gcc and immediately error when it encounters an unknown flag by
adding -Werror=unknown-warning-option to CLANG_FLAGS. This can be added
unconditionally for clang because it is supported by at least 3.0.0,
according to godbolt [1] and 4.0.0, according to its documentation [2],
which is far earlier than we typically support.
[1]: https://godbolt.org/z/7F7rm3
[2]: https://releases.llvm.org/4.0.0/tools/clang/docs/DiagnosticsReference.html#wunknown-warning-option
Link: https://github.com/ClangBuiltLinux/linux/issues/511
Link: https://github.com/ClangBuiltLinux/linux/issues/517
Suggested-by: Peter Smith <peter.smith@linaro.org>
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Tested-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2019-06-11 21:43:31 +03:00
CLANG_FLAGS += -Werror= unknown-warning-option
2018-11-06 06:04:55 +03:00
KBUILD_CFLAGS += $( CLANG_FLAGS)
KBUILD_AFLAGS += $( CLANG_FLAGS)
2018-11-12 07:21:15 +03:00
export CLANG_FLAGS
2017-11-07 22:46:13 +03:00
e n d i f
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 03:21:43 +03:00
# The expansion should be delayed until arch/$(SRCARCH)/Makefile is included.
# Some architectures define CROSS_COMPILE in arch/$(SRCARCH)/Makefile.
# CC_VERSION_TEXT is referenced from Kconfig (so it needs export),
# and from include/config/auto.conf.cmd to detect the compiler upgrade.
2019-05-09 10:35:55 +03:00
CC_VERSION_TEXT = $( shell $( CC) --version 2>/dev/null | head -n 1)
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 03:21:43 +03:00
2019-08-10 18:53:03 +03:00
i f d e f c o n f i g - b u i l d
2005-04-17 02:20:36 +04:00
# ===========================================================================
# *config targets only - make sure prerequisites are updated, and descend
# in scripts/kconfig to make the *config target
# Read arch specific Makefile to set KBUILD_DEFCONFIG as needed.
# KBUILD_DEFCONFIG may point out an alternative default configuration
# used for 'make defconfig'
2015-03-27 14:43:36 +03:00
i n c l u d e a r c h / $( SRCARCH ) / M a k e f i l e
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 03:21:43 +03:00
export KBUILD_DEFCONFIG KBUILD_KCONFIG CC_VERSION_TEXT
2005-04-17 02:20:36 +04:00
2019-08-22 07:46:13 +03:00
config : outputmakefile scripts_basic FORCE
2008-12-14 01:00:45 +03:00
$( Q) $( MAKE) $( build) = scripts/kconfig $@
2019-08-22 07:46:13 +03:00
%config : outputmakefile scripts_basic FORCE
2005-04-17 02:20:36 +04:00
$( Q) $( MAKE) $( build) = scripts/kconfig $@
2019-08-10 18:53:03 +03:00
e l s e #!config-build
2005-04-17 02:20:36 +04:00
# ===========================================================================
# Build targets only - this includes vmlinux, arch specific targets, clean
# targets and others. In general all targets except *config targets.
2017-10-04 06:56:06 +03:00
# If building an external module we do not care about the all: rule
# but instead _all depend on modules
PHONY += all
i f e q ( $( KBUILD_EXTMOD ) , )
_all : all
e l s e
_all : modules
e n d i f
# 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.
# 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.
i f e q ( $( MAKECMDGOALS ) , m o d u l e s )
KBUILD_BUILTIN := $( if $( CONFIG_MODVERSIONS) ,1)
e n d i f
# 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
2019-10-03 10:58:24 +03:00
i f n e q ( $( filter all _all modules nsdeps ,$ ( MAKECMDGOALS ) ) , )
2017-10-04 06:56:06 +03:00
KBUILD_MODULES := 1
e n d i f
i f e q ( $( MAKECMDGOALS ) , )
KBUILD_MODULES := 1
e n d i f
export KBUILD_MODULES KBUILD_BUILTIN
2019-08-10 18:53:03 +03:00
i f d e f n e e d - c o n f i g
2019-04-27 06:33:36 +03:00
i n c l u d e i n c l u d e / c o n f i g / a u t o . c o n f
e n d i f
2005-04-17 02:20:36 +04:00
i f e q ( $( KBUILD_EXTMOD ) , )
# Objects we will link into vmlinux / subdirs we need to visit
init-y := init/
2019-01-11 12:52:00 +03:00
drivers-y := drivers/ sound/
2019-04-27 06:33:36 +03:00
drivers-$(CONFIG_SAMPLES) += samples/
2019-07-01 03:58:45 +03:00
drivers-$(CONFIG_KERNEL_HEADER_TEST) += include/
2005-04-17 02:20:36 +04:00
net-y := net/
libs-y := lib/
core-y := usr/
2015-09-22 11:47:29 +03:00
virt-y := virt/
2005-04-17 02:20:36 +04:00
e n d i f # 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 03:21:43 +03: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
CFLAGS_GCOV := -fprofile-arcs -ftest-coverage \
$( call cc-option,-fno-tree-loop-im) \
$( call cc-disable-warning,maybe-uninitialized,)
2018-05-28 12:22:04 +03: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 03:21:43 +03: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 20:59:56 +03:00
# The arch Makefiles can override CC_FLAGS_FTRACE. We may also append it later.
i f d e f C O N F I G _ F U N C T I O N _ T R A C E R
CC_FLAGS_FTRACE := -pg
e n d i f
2019-03-26 09:11:12 +03:00
RETPOLINE_CFLAGS_GCC := -mindirect-branch= thunk-extern -mindirect-branch-register
RETPOLINE_VDSO_CFLAGS_GCC := -mindirect-branch= thunk-inline -mindirect-branch-register
RETPOLINE_CFLAGS_CLANG := -mretpoline-external-thunk
RETPOLINE_VDSO_CFLAGS_CLANG := -mretpoline
RETPOLINE_CFLAGS := $( call cc-option,$( RETPOLINE_CFLAGS_GCC) ,$( call cc-option,$( RETPOLINE_CFLAGS_CLANG) ) )
RETPOLINE_VDSO_CFLAGS := $( call cc-option,$( RETPOLINE_VDSO_CFLAGS_GCC) ,$( call cc-option,$( RETPOLINE_VDSO_CFLAGS_CLANG) ) )
export RETPOLINE_CFLAGS
export RETPOLINE_VDSO_CFLAGS
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 03:21:43 +03:00
i n c l u d e a r c h / $( SRCARCH ) / M a k e f i l e
2005-04-17 02:20:36 +04:00
2019-08-10 18:53:03 +03:00
i f d e f n e e d - c o n f i g
i f d e f m a y - s y n c - c o n f i g
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 03:21:43 +03: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 05:13:48 +03:00
i n c l u d e i n c l u d e / c o n f i g / a u t o . c o n f . c m d
2005-04-17 02:20:36 +04:00
2019-02-22 10:40:11 +03: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-17 02:20:36 +04:00
2018-02-13 10:58:20 +03: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 10:40:10 +03:00
#
# This exploits the 'multi-target pattern rule' trick.
# The syncconfig should be executed only once to make all the targets.
%/auto.conf %/auto.conf.cmd %/tristate.conf : $( KCONFIG_CONFIG )
2018-03-01 09:34:37 +03:00
$( Q) $( MAKE) -f $( srctree) /Makefile syncconfig
2019-08-10 18:53:03 +03:00
e l s e # !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 10:46:34 +03: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.
# Use auto.conf to trigger the test
2006-08-07 23:01:36 +04:00
PHONY += include/config/auto.conf
include/config/auto.conf :
2009-10-18 02:49:24 +04:00
$( Q) test -e include/generated/autoconf.h -a -e $@ || ( \
2012-07-08 01:04:40 +04:00
echo >& 2; \
echo >& 2 " ERROR: Kernel configuration is invalid." ; \
echo >& 2 " include/generated/autoconf.h or $@ are missing. " ; \
echo >& 2 " Run 'make oldconfig && make prepare' on kernel src to fix it." ; \
echo >& 2 ; \
2006-08-07 23:01:36 +04:00
/bin/false)
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 10:46:34 +03:00
e n d i f # may-sync-config
2019-08-10 18:53:03 +03:00
e n d i f # need-config
2005-04-17 02:20:36 +04:00
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 11:54:12 +04:00
KBUILD_CFLAGS += $( call cc-option,-fno-delete-null-pointer-checks,)
2016-10-12 20:23:41 +03:00
KBUILD_CFLAGS += $( call cc-disable-warning,frame-address,)
2017-07-13 05:25:47 +03:00
KBUILD_CFLAGS += $( call cc-disable-warning, format-truncation)
KBUILD_CFLAGS += $( call cc-disable-warning, format-overflow)
2019-05-01 21:05:41 +03:00
KBUILD_CFLAGS += $( call cc-disable-warning, address-of-packed-member)
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 11:54:12 +04:00
2019-08-20 20:09:40 +03:00
i f d e f C O N F I G _ C C _ O P T I M I Z E _ F O R _ P E R F O R M A N C E
KBUILD_CFLAGS += -O2
e l s e i f d e f C O N F I G _ C C _ O P T I M I Z E _ F O R _ P E R F O R M A N C E _ O 3
KBUILD_CFLAGS += -O3
e l s e i f d e f C O N F I G _ C C _ O P T I M I Z E _ F O R _ S I Z E
KBUILD_CFLAGS += -Os
2016-04-25 18:35:28 +03:00
e n d i f
2005-04-17 02:20:36 +04:00
2019-02-21 07:13:38 +03:00
i f d e f C O N F I G _ C C _ D I S A B L E _ W A R N _ M A Y B E _ U N I N I T I A L I Z E D
KBUILD_CFLAGS += -Wno-maybe-uninitialized
e n d i f
Kbuild: enable -Wmaybe-uninitialized warning for "make W=1"
Traditionally, we have always had warnings about uninitialized variables
enabled, as this is part of -Wall, and generally a good idea [1], but it
also always produced false positives, mainly because this is a variation
of the halting problem and provably impossible to get right in all cases
[2].
Various people have identified cases that are particularly bad for false
positives, and in commit e74fc973b6e5 ("Turn off -Wmaybe-uninitialized
when building with -Os"), I turned off the warning for any build that
was done with CC_OPTIMIZE_FOR_SIZE. This drastically reduced the number
of false positive warnings in the default build but unfortunately had
the side effect of turning the warning off completely in 'allmodconfig'
builds, which in turn led to a lot of warnings (both actual bugs, and
remaining false positives) to go in unnoticed.
With commit 877417e6ffb9 ("Kbuild: change CC_OPTIMIZE_FOR_SIZE
definition") enabled the warning again for allmodconfig builds in v4.7
and in v4.8-rc1, I had finally managed to address all warnings I get in
an ARM allmodconfig build and most other maybe-uninitialized warnings
for ARM randconfig builds.
However, commit 6e8d666e9253 ("Disable "maybe-uninitialized" warning
globally") was merged at the same time and disabled it completely for
all configurations, because of false-positive warnings on x86 that I had
not addressed until then. This caused a lot of actual bugs to get
merged into mainline, and I sent several dozen patches for these during
the v4.9 development cycle. Most of these are actual bugs, some are for
correct code that is safe because it is only called under external
constraints that make it impossible to run into the case that gcc sees,
and in a few cases gcc is just stupid and finds something that can
obviously never happen.
I have now done a few thousand randconfig builds on x86 and collected
all patches that I needed to address every single warning I got (I can
provide the combined patch for the other warnings if anyone is
interested), so I hope we can get the warning back and let people catch
the actual bugs earlier.
This reverts the change to disable the warning completely and for now
brings it back at the "make W=1" level, so we can get it merged into
mainline without introducing false positives. A follow-up patch enables
it on all levels unless some configuration option turns it off because
of false-positives.
Link: https://rusty.ozlabs.org/?p=232 [1]
Link: https://gcc.gnu.org/wiki/Better_Uninitialized_Warnings [2]
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-11-10 19:44:44 +03:00
./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-07 03:08:43 +04:00
# Tell gcc to never replace conditional load with a non-conditional one
KBUILD_CFLAGS += $( call cc-option,--param= allow-store-data-races= 0)
2017-11-18 02:30:50 +03:00
i n c l u d e s c r i p t s / M a k e f i l e . k c o v
2016-05-24 01:09:38 +03:00
i n c l u d e s c r i p t s / M a k e f i l e . g c c - p l u g i n s
2012-03-28 22:51:18 +04:00
i f d e f C O N F I G _ R E A D A B L E _ A S M
# 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
KBUILD_CFLAGS += $( call cc-option,-fno-reorder-blocks,) \
$( call cc-option,-fno-ipa-cp-clone,) \
$( call cc-option,-fno-partial-inlining)
e n d i f
2009-06-05 03:29:08 +04:00
i f n e q ( $( CONFIG_FRAME_WARN ) , 0 )
2008-02-22 17:15:03 +03:00
KBUILD_CFLAGS += $( call cc-option,-Wframe-larger-than= ${ CONFIG_FRAME_WARN } )
e n d i f
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 12:22:00 +03:00
stackp-flags-$(CONFIG_CC_HAS_STACKPROTECTOR_NONE) := -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 06:21:18 +03: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 12:22:00 +03:00
KBUILD_CFLAGS += $( stackp-flags-y)
2008-02-14 00:43:28 +03:00
2018-10-30 16:26:33 +03:00
i f d e f C O N F I G _ C C _ I S _ C L A N G
2019-05-10 17:10:09 +03:00
KBUILD_CPPFLAGS += -Qunused-arguments
KBUILD_CFLAGS += -Wno-format-invalid-specifier
KBUILD_CFLAGS += -Wno-gnu
2017-11-27 15:15:13 +03:00
# Quiet clang warning: comparison of unsigned expression < 0 is always false
2019-05-10 17:10:09 +03:00
KBUILD_CFLAGS += -Wno-tautological-compare
2017-11-27 15:15:13 +03:00
# CLANG uses a _MergedGlobals as optimization, but this breaks modpost, as the
# source of a reference will be _MergedGlobals and not on of the whitelisted names.
# See modpost pattern 2
2019-05-10 17:10:09 +03:00
KBUILD_CFLAGS += -mno-global-merge
2017-11-27 15:15:13 +03:00
e l s e
# These warnings generated too much noise in a regular build.
# Use make W=1 to enable them (see scripts/Makefile.extrawarn)
2018-10-02 04:32:23 +03:00
KBUILD_CFLAGS += -Wno-unused-but-set-variable
2019-08-27 03:41:55 +03:00
# Warn about unmarked fall-throughs in switch statement.
# Disabled for clang while comment to attribute conversion happens and
# https://github.com/ClangBuiltLinux/linux/issues/636 is discussed.
KBUILD_CFLAGS += $( call cc-option,-Wimplicit-fallthrough,)
2017-11-27 15:15:13 +03:00
e n d i f
2018-02-07 02:46:51 +03:00
KBUILD_CFLAGS += $( call cc-disable-warning, unused-const-variable)
2005-04-17 02:20:36 +04:00
i f d e f C O N F I G _ F R A M E _ P O I N T E R
2007-10-15 00:21:35 +04:00
KBUILD_CFLAGS += -fno-omit-frame-pointer -fno-optimize-sibling-calls
2005-04-17 02:20:36 +04:00
e l s e
2010-08-10 22:20:53 +04: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.
i f n d e f C O N F I G _ F U N C T I O N _ T R A C E R
2007-10-15 00:21:35 +04:00
KBUILD_CFLAGS += -fomit-frame-pointer
2005-04-17 02:20:36 +04:00
e n d i f
2010-08-10 22:20:53 +04:00
e n d i f
2005-04-17 02:20:36 +04:00
2019-04-10 18:48:31 +03:00
# Initialize all stack variables with a pattern, if desired.
i f d e f C O N F I G _ I N I T _ S T A C K _ A L L
KBUILD_CFLAGS += -ftrivial-auto-var-init= pattern
e n d i f
kbuild: Disable extra debugging info in .s output
Modern gcc adds view assignments, reset assertion checking in .loc
directives and a couple more additional debug markers, which clutters
the asm output unnecessarily:
For example:
bsp_resume:
.LFB3466:
.loc 1 1868 1 is_stmt 1 view -0
.cfi_startproc
.loc 1 1869 2 view .LVU73
# arch/x86/kernel/cpu/common.c:1869: if (this_cpu->c_bsp_resume)
.loc 1 1869 14 is_stmt 0 view .LVU74
movq this_cpu(%rip), %rax # this_cpu, this_cpu
movq 64(%rax), %rax # this_cpu.94_1->c_bsp_resume, _2
# arch/x86/kernel/cpu/common.c:1869: if (this_cpu->c_bsp_resume)
.loc 1 1869 5 view .LVU75
testq %rax, %rax # _2
je .L8 #,
.loc 1 1870 3 is_stmt 1 view .LVU76
movq $boot_cpu_data, %rdi #,
jmp __x86_indirect_thunk_rax
or
.loc 2 57 9 view .LVU478
.loc 2 57 9 view .LVU479
.loc 2 57 9 view .LVU480
.loc 2 57 9 view .LVU481
.LBB1385:
.LBB1383:
.LBB1379:
.LBB1377:
.LBB1375:
.loc 2 57 9 view .LVU482
.loc 2 57 9 view .LVU483
movl %edi, %edx # cpu, cpu
.LVL87:
.loc 2 57 9 is_stmt 0 view .LVU484
That MOV in there is drowned in debugging information and latter makes
it hard to follow the asm. And that DWARF info is not really needed for
asm output staring.
Disable the debug information generation which clutters the asm output
unnecessarily:
bsp_resume:
# arch/x86/kernel/cpu/common.c:1869: if (this_cpu->c_bsp_resume)
movq this_cpu(%rip), %rax # this_cpu, this_cpu
movq 64(%rax), %rax # this_cpu.94_1->c_bsp_resume, _2
# arch/x86/kernel/cpu/common.c:1869: if (this_cpu->c_bsp_resume)
testq %rax, %rax # _2
je .L8 #,
# arch/x86/kernel/cpu/common.c:1870: this_cpu->c_bsp_resume(&boot_cpu_data);
movq $boot_cpu_data, %rdi #,
jmp __x86_indirect_thunk_rax
.L8:
# arch/x86/kernel/cpu/common.c:1871: }
rep ret
.size bsp_resume, .-bsp_resume
[ bp: write commit message. ]
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
2019-02-10 09:51:00 +03:00
DEBUG_CFLAGS := $( call cc-option, -fno-var-tracking-assignments)
Fix gcc-4.9.0 miscompilation of load_balance() in scheduler
Michel Dänzer and a couple of other people reported inexplicable random
oopses in the scheduler, and the cause turns out to be gcc mis-compiling
the load_balance() function when debugging is enabled. The gcc bug
apparently goes back to gcc-4.5, but slight optimization changes means
that it now showed up as a problem in 4.9.0 and 4.9.1.
The instruction scheduling problem causes gcc to schedule a spill
operation to before the stack frame has been created, which in turn can
corrupt the spilled value if an interrupt comes in. There may be other
effects of this bug too, but that's the code generation problem seen in
Michel's case.
This is fixed in current gcc HEAD, but the workaround as suggested by
Markus Trippelsdorf is pretty simple: use -fno-var-tracking-assignments
when compiling the kernel, which disables the gcc code that causes the
problem. This can result in slightly worse debug information for
variable accesses, but that is infinitely preferable to actual code
generation problems.
Doing this unconditionally (not just for CONFIG_DEBUG_INFO) also allows
non-debug builds to verify that the debug build would be identical: we
can do
export GCC_COMPARE_DEBUG=1
to make gcc internally verify that the result of the build is
independent of the "-g" flag (it will make the compiler build everything
twice, toggling the debug flag, and compare the results).
Without the "-fno-var-tracking-assignments" option, the build would fail
(even with 4.8.3 that didn't show the actual stack frame bug) with a gcc
compare failure.
See also gcc bugzilla:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61801
Reported-by: Michel Dänzer <michel@daenzer.net>
Suggested-by: Markus Trippelsdorf <markus@trippelsdorf.de>
Cc: Jakub Jelinek <jakub@redhat.com>
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-07-27 01:52:01 +04:00
2005-04-17 02:20:36 +04:00
i f d e f C O N F I G _ D E B U G _ I N F O
2014-07-30 22:50:18 +04:00
i f d e f C O N F I G _ D E B U G _ I N F O _ S P L I T
2019-02-22 10:56:09 +03:00
DEBUG_CFLAGS += -gsplit-dwarf
2014-07-30 22:50:18 +04:00
e l s e
kbuild: Disable extra debugging info in .s output
Modern gcc adds view assignments, reset assertion checking in .loc
directives and a couple more additional debug markers, which clutters
the asm output unnecessarily:
For example:
bsp_resume:
.LFB3466:
.loc 1 1868 1 is_stmt 1 view -0
.cfi_startproc
.loc 1 1869 2 view .LVU73
# arch/x86/kernel/cpu/common.c:1869: if (this_cpu->c_bsp_resume)
.loc 1 1869 14 is_stmt 0 view .LVU74
movq this_cpu(%rip), %rax # this_cpu, this_cpu
movq 64(%rax), %rax # this_cpu.94_1->c_bsp_resume, _2
# arch/x86/kernel/cpu/common.c:1869: if (this_cpu->c_bsp_resume)
.loc 1 1869 5 view .LVU75
testq %rax, %rax # _2
je .L8 #,
.loc 1 1870 3 is_stmt 1 view .LVU76
movq $boot_cpu_data, %rdi #,
jmp __x86_indirect_thunk_rax
or
.loc 2 57 9 view .LVU478
.loc 2 57 9 view .LVU479
.loc 2 57 9 view .LVU480
.loc 2 57 9 view .LVU481
.LBB1385:
.LBB1383:
.LBB1379:
.LBB1377:
.LBB1375:
.loc 2 57 9 view .LVU482
.loc 2 57 9 view .LVU483
movl %edi, %edx # cpu, cpu
.LVL87:
.loc 2 57 9 is_stmt 0 view .LVU484
That MOV in there is drowned in debugging information and latter makes
it hard to follow the asm. And that DWARF info is not really needed for
asm output staring.
Disable the debug information generation which clutters the asm output
unnecessarily:
bsp_resume:
# arch/x86/kernel/cpu/common.c:1869: if (this_cpu->c_bsp_resume)
movq this_cpu(%rip), %rax # this_cpu, this_cpu
movq 64(%rax), %rax # this_cpu.94_1->c_bsp_resume, _2
# arch/x86/kernel/cpu/common.c:1869: if (this_cpu->c_bsp_resume)
testq %rax, %rax # _2
je .L8 #,
# arch/x86/kernel/cpu/common.c:1870: this_cpu->c_bsp_resume(&boot_cpu_data);
movq $boot_cpu_data, %rdi #,
jmp __x86_indirect_thunk_rax
.L8:
# arch/x86/kernel/cpu/common.c:1871: }
rep ret
.size bsp_resume, .-bsp_resume
[ bp: write commit message. ]
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
2019-02-10 09:51:00 +03:00
DEBUG_CFLAGS += -g
2014-07-30 22:50:18 +04:00
e n d i f
2014-02-15 03:19:17 +04:00
KBUILD_AFLAGS += -Wa,-gdwarf-2
2005-04-17 02:20:36 +04:00
e n d i f
2014-07-30 22:50:19 +04:00
i f d e f C O N F I G _ D E B U G _ I N F O _ D W A R F 4
2019-02-22 10:56:09 +03:00
DEBUG_CFLAGS += -gdwarf-4
2014-07-30 22:50:19 +04:00
e n d i f
2005-04-17 02:20:36 +04:00
2010-07-14 17:43:52 +04:00
i f d e f C O N F I G _ D E B U G _ I N F O _ R E D U C E D
kbuild: Disable extra debugging info in .s output
Modern gcc adds view assignments, reset assertion checking in .loc
directives and a couple more additional debug markers, which clutters
the asm output unnecessarily:
For example:
bsp_resume:
.LFB3466:
.loc 1 1868 1 is_stmt 1 view -0
.cfi_startproc
.loc 1 1869 2 view .LVU73
# arch/x86/kernel/cpu/common.c:1869: if (this_cpu->c_bsp_resume)
.loc 1 1869 14 is_stmt 0 view .LVU74
movq this_cpu(%rip), %rax # this_cpu, this_cpu
movq 64(%rax), %rax # this_cpu.94_1->c_bsp_resume, _2
# arch/x86/kernel/cpu/common.c:1869: if (this_cpu->c_bsp_resume)
.loc 1 1869 5 view .LVU75
testq %rax, %rax # _2
je .L8 #,
.loc 1 1870 3 is_stmt 1 view .LVU76
movq $boot_cpu_data, %rdi #,
jmp __x86_indirect_thunk_rax
or
.loc 2 57 9 view .LVU478
.loc 2 57 9 view .LVU479
.loc 2 57 9 view .LVU480
.loc 2 57 9 view .LVU481
.LBB1385:
.LBB1383:
.LBB1379:
.LBB1377:
.LBB1375:
.loc 2 57 9 view .LVU482
.loc 2 57 9 view .LVU483
movl %edi, %edx # cpu, cpu
.LVL87:
.loc 2 57 9 is_stmt 0 view .LVU484
That MOV in there is drowned in debugging information and latter makes
it hard to follow the asm. And that DWARF info is not really needed for
asm output staring.
Disable the debug information generation which clutters the asm output
unnecessarily:
bsp_resume:
# arch/x86/kernel/cpu/common.c:1869: if (this_cpu->c_bsp_resume)
movq this_cpu(%rip), %rax # this_cpu, this_cpu
movq 64(%rax), %rax # this_cpu.94_1->c_bsp_resume, _2
# arch/x86/kernel/cpu/common.c:1869: if (this_cpu->c_bsp_resume)
testq %rax, %rax # _2
je .L8 #,
# arch/x86/kernel/cpu/common.c:1870: this_cpu->c_bsp_resume(&boot_cpu_data);
movq $boot_cpu_data, %rdi #,
jmp __x86_indirect_thunk_rax
.L8:
# arch/x86/kernel/cpu/common.c:1871: }
rep ret
.size bsp_resume, .-bsp_resume
[ bp: write commit message. ]
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
2019-02-10 09:51:00 +03:00
DEBUG_CFLAGS += $( call cc-option, -femit-struct-debug-baseonly) \
2013-02-08 01:58:40 +04:00
$( call cc-option,-fno-var-tracking)
2010-07-14 17:43:52 +04:00
e n d i f
kbuild: Disable extra debugging info in .s output
Modern gcc adds view assignments, reset assertion checking in .loc
directives and a couple more additional debug markers, which clutters
the asm output unnecessarily:
For example:
bsp_resume:
.LFB3466:
.loc 1 1868 1 is_stmt 1 view -0
.cfi_startproc
.loc 1 1869 2 view .LVU73
# arch/x86/kernel/cpu/common.c:1869: if (this_cpu->c_bsp_resume)
.loc 1 1869 14 is_stmt 0 view .LVU74
movq this_cpu(%rip), %rax # this_cpu, this_cpu
movq 64(%rax), %rax # this_cpu.94_1->c_bsp_resume, _2
# arch/x86/kernel/cpu/common.c:1869: if (this_cpu->c_bsp_resume)
.loc 1 1869 5 view .LVU75
testq %rax, %rax # _2
je .L8 #,
.loc 1 1870 3 is_stmt 1 view .LVU76
movq $boot_cpu_data, %rdi #,
jmp __x86_indirect_thunk_rax
or
.loc 2 57 9 view .LVU478
.loc 2 57 9 view .LVU479
.loc 2 57 9 view .LVU480
.loc 2 57 9 view .LVU481
.LBB1385:
.LBB1383:
.LBB1379:
.LBB1377:
.LBB1375:
.loc 2 57 9 view .LVU482
.loc 2 57 9 view .LVU483
movl %edi, %edx # cpu, cpu
.LVL87:
.loc 2 57 9 is_stmt 0 view .LVU484
That MOV in there is drowned in debugging information and latter makes
it hard to follow the asm. And that DWARF info is not really needed for
asm output staring.
Disable the debug information generation which clutters the asm output
unnecessarily:
bsp_resume:
# arch/x86/kernel/cpu/common.c:1869: if (this_cpu->c_bsp_resume)
movq this_cpu(%rip), %rax # this_cpu, this_cpu
movq 64(%rax), %rax # this_cpu.94_1->c_bsp_resume, _2
# arch/x86/kernel/cpu/common.c:1869: if (this_cpu->c_bsp_resume)
testq %rax, %rax # _2
je .L8 #,
# arch/x86/kernel/cpu/common.c:1870: this_cpu->c_bsp_resume(&boot_cpu_data);
movq $boot_cpu_data, %rdi #,
jmp __x86_indirect_thunk_rax
.L8:
# arch/x86/kernel/cpu/common.c:1871: }
rep ret
.size bsp_resume, .-bsp_resume
[ bp: write commit message. ]
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
2019-02-10 09:51:00 +03:00
KBUILD_CFLAGS += $( DEBUG_CFLAGS)
export DEBUG_CFLAGS
2008-10-07 03:06:12 +04:00
i f d e f C O N F I G _ F U N C T I O N _ T R A C E R
2018-08-06 16:17:44 +03:00
i f d e f C O N F I G _ F T R A C E _ M C O U N T _ R E C O R D
# gcc 5 supports generating the mcount tables directly
ifeq ( $( call cc-option-yn,-mrecord-mcount) ,y)
CC_FLAGS_FTRACE += -mrecord-mcount
export CC_USING_RECORD_MCOUNT := 1
endif
2018-08-06 16:17:46 +03: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 16:17:44 +03:00
e n d i f
2011-02-09 21:15:59 +03:00
i f d e f C O N F I G _ H A V E _ F E N T R Y
2018-08-06 16:17:42 +03:00
ifeq ( $( call cc-option-yn, -mfentry) ,y)
CC_FLAGS_FTRACE += -mfentry
CC_FLAGS_USING += -DCC_USING_FENTRY
endif
2011-02-09 21:15:59 +03:00
e n d i f
2018-08-06 16:17:42 +03:00
export CC_FLAGS_FTRACE
KBUILD_CFLAGS += $( CC_FLAGS_FTRACE) $( CC_FLAGS_USING)
KBUILD_AFLAGS += $( CC_FLAGS_USING)
2010-10-14 01:12:30 +04:00
i f d e f C O N F I G _ D Y N A M I C _ F T R A C E
2010-10-15 07:32:44 +04:00
ifdef CONFIG_HAVE_C_RECORDMCOUNT
2010-10-14 01:12:30 +04:00
BUILD_C_RECORDMCOUNT := y
export BUILD_C_RECORDMCOUNT
endif
e n d i f
2008-05-12 23:20:42 +04:00
e n d i f
2008-01-21 23:31:44 +03:00
# We trigger additional mismatches with less inlining
i f d e f C O N F I G _ D E B U G _ S E C T I O N _ M I S M A T C H
KBUILD_CFLAGS += $( call cc-option, -fno-inline-functions-called-once)
e n d i f
2017-04-14 09:17:26 +03:00
i f d e f C O N F I G _ L D _ D E A D _ C O D E _ D A T A _ E L I M I N A T I O N
2018-08-22 16:51:09 +03:00
KBUILD_CFLAGS_KERNEL += -ffunction-sections -fdata-sections
LDFLAGS_vmlinux += --gc-sections
2017-04-14 09:17:26 +03:00
e n d i f
2019-04-04 21:44:11 +03:00
i f d e f C O N F I G _ L I V E P A T C H
KBUILD_CFLAGS += $( call cc-option, -flive-patching= inline-clone)
e n d i f
2005-05-01 03:51:42 +04:00
# arch Makefile may override CC so keep this after arch Makefile is included
kbuild: remove kbuild cache
The kbuild cache was introduced to remember the result of shell
commands, some of which are expensive to compute, such as
$(call cc-option,...).
However, this turned out not so clever as I had first expected.
Actually, it is problematic. For example, "$(CC) -print-file-name"
is cached. If the compiler is updated, the stale search path causes
build error, which is difficult to figure out. Another problem
scenario is cache files could be touched while install targets are
running under the root permission. We can patch them if desired,
but the build infrastructure is getting uglier and uglier.
Now, we are going to move compiler flag tests to the configuration
phase. If this is completed, the result of compiler tests will be
naturally cached in the .config file. We will not have performance
issues of incremental building since this testing only happens at
Kconfig time.
To start this work with a cleaner code base, remove the kbuild
cache first.
Revert the following commits:
Commit 9a234a2e3843 ("kbuild: create directory for make cache only when necessary")
Commit e17c400ae194 ("kbuild: shrink .cache.mk when it exceeds 1000 lines")
Commit 4e56207130ed ("kbuild: Cache a few more calls to the compiler")
Commit 3298b690b21c ("kbuild: Add a cache for generated variables")
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Kees Cook <keescook@chromium.org>
2018-05-28 12:21:38 +03:00
NOSTDINC_FLAGS += -nostdinc -isystem $( shell $( CC) -print-file-name= include)
2005-05-01 03:51:42 +04:00
2005-04-17 02:20:36 +04:00
# warn about C99 declaration after statement
2018-10-01 12:44:37 +03:00
KBUILD_CFLAGS += -Wdeclaration-after-statement
2005-04-17 02:20:36 +04:00
2018-06-26 01:59:34 +03:00
# Variable Length Arrays (VLAs) should not be used anywhere in the kernel
2019-05-09 09:45:49 +03:00
KBUILD_CFLAGS += -Wvla
2018-06-26 01:59:34 +03:00
2006-06-25 02:07:55 +04:00
# disable pointer signed / unsigned warnings in gcc 4.0
2018-10-01 12:44:36 +03:00
KBUILD_CFLAGS += -Wno-pointer-sign
2005-04-17 02:20:36 +04:00
2018-08-31 00:47:28 +03:00
# disable stringop warnings in gcc 8+
KBUILD_CFLAGS += $( call cc-disable-warning, stringop-truncation)
2009-04-09 15:34:34 +04:00
# disable invalid "can't wrap" optimizations for signed / pointers
2009-07-12 22:25:04 +04:00
KBUILD_CFLAGS += $( call cc-option,-fno-strict-overflow)
2009-03-20 01:53:19 +03:00
kbuild: disable clang's default use of -fmerge-all-constants
Prasad reported that he has seen crashes in BPF subsystem with netd
on Android with arm64 in the form of (note, the taint is unrelated):
[ 4134.721483] Unable to handle kernel paging request at virtual address 800000001
[ 4134.820925] Mem abort info:
[ 4134.901283] Exception class = DABT (current EL), IL = 32 bits
[ 4135.016736] SET = 0, FnV = 0
[ 4135.119820] EA = 0, S1PTW = 0
[ 4135.201431] Data abort info:
[ 4135.301388] ISV = 0, ISS = 0x00000021
[ 4135.359599] CM = 0, WnR = 0
[ 4135.470873] user pgtable: 4k pages, 39-bit VAs, pgd = ffffffe39b946000
[ 4135.499757] [0000000800000001] *pgd=0000000000000000, *pud=0000000000000000
[ 4135.660725] Internal error: Oops: 96000021 [#1] PREEMPT SMP
[ 4135.674610] Modules linked in:
[ 4135.682883] CPU: 5 PID: 1260 Comm: netd Tainted: G S W 4.14.19+ #1
[ 4135.716188] task: ffffffe39f4aa380 task.stack: ffffff801d4e0000
[ 4135.731599] PC is at bpf_prog_add+0x20/0x68
[ 4135.741746] LR is at bpf_prog_inc+0x20/0x2c
[ 4135.751788] pc : [<ffffff94ab7ad584>] lr : [<ffffff94ab7ad638>] pstate: 60400145
[ 4135.769062] sp : ffffff801d4e3ce0
[...]
[ 4136.258315] Process netd (pid: 1260, stack limit = 0xffffff801d4e0000)
[ 4136.273746] Call trace:
[...]
[ 4136.442494] 3ca0: ffffff94ab7ad584 0000000060400145 ffffffe3a01bf8f8 0000000000000006
[ 4136.460936] 3cc0: 0000008000000000 ffffff94ab844204 ffffff801d4e3cf0 ffffff94ab7ad584
[ 4136.479241] [<ffffff94ab7ad584>] bpf_prog_add+0x20/0x68
[ 4136.491767] [<ffffff94ab7ad638>] bpf_prog_inc+0x20/0x2c
[ 4136.504536] [<ffffff94ab7b5d08>] bpf_obj_get_user+0x204/0x22c
[ 4136.518746] [<ffffff94ab7ade68>] SyS_bpf+0x5a8/0x1a88
Android's netd was basically pinning the uid cookie BPF map in BPF
fs (/sys/fs/bpf/traffic_cookie_uid_map) and later on retrieving it
again resulting in above panic. Issue is that the map was wrongly
identified as a prog! Above kernel was compiled with clang 4.0,
and it turns out that clang decided to merge the bpf_prog_iops and
bpf_map_iops into a single memory location, such that the two i_ops
could then not be distinguished anymore.
Reason for this miscompilation is that clang has the more aggressive
-fmerge-all-constants enabled by default. In fact, clang source code
has a comment about it in lib/AST/ExprConstant.cpp on why it is okay
to do so:
Pointers with different bases cannot represent the same object.
(Note that clang defaults to -fmerge-all-constants, which can
lead to inconsistent results for comparisons involving the address
of a constant; this generally doesn't matter in practice.)
The issue never appeared with gcc however, since gcc does not enable
-fmerge-all-constants by default and even *explicitly* states in
it's option description that using this flag results in non-conforming
behavior, quote from man gcc:
Languages like C or C++ require each variable, including multiple
instances of the same variable in recursive calls, to have distinct
locations, so using this option results in non-conforming behavior.
There are also various clang bug reports open on that matter [1],
where clang developers acknowledge the non-conforming behavior,
and refer to disabling it with -fno-merge-all-constants. But even
if this gets fixed in clang today, there are already users out there
that triggered this. Thus, fix this issue by explicitly adding
-fno-merge-all-constants to the kernel's Makefile to generically
disable this optimization, since potentially other places in the
kernel could subtly break as well.
Note, there is also a flag called -fmerge-constants (not supported
by clang), which is more conservative and only applies to strings
and it's enabled in gcc's -O/-O2/-O3/-Os optimization levels. In
gcc's code, the two flags -fmerge-{all-,}constants share the same
variable internally, so when disabling it via -fno-merge-all-constants,
then we really don't merge any const data (e.g. strings), and text
size increases with gcc (14,927,214 -> 14,942,646 for vmlinux.o).
$ gcc -fverbose-asm -O2 foo.c -S -o foo.S
-> foo.S lists -fmerge-constants under options enabled
$ gcc -fverbose-asm -O2 -fno-merge-all-constants foo.c -S -o foo.S
-> foo.S doesn't list -fmerge-constants under options enabled
$ gcc -fverbose-asm -O2 -fno-merge-all-constants -fmerge-constants foo.c -S -o foo.S
-> foo.S lists -fmerge-constants under options enabled
Thus, as a workaround we need to set both -fno-merge-all-constants
*and* -fmerge-constants in the Makefile in order for text size to
stay as is.
[1] https://bugs.llvm.org/show_bug.cgi?id=18538
Reported-by: Prasad Sodagudi <psodagud@codeaurora.org>
Signed-off-by: Daniel Borkmann <daniel@iogearbox.net>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Chenbo Feng <fengc@google.com>
Cc: Richard Smith <richard-llvm@metafoo.co.uk>
Cc: Chandler Carruth <chandlerc@gmail.com>
Cc: linux-kernel@vger.kernel.org
Tested-by: Prasad Sodagudi <psodagud@codeaurora.org>
Acked-by: Alexei Starovoitov <ast@kernel.org>
Signed-off-by: Alexei Starovoitov <ast@kernel.org>
2018-03-21 03:18:24 +03:00
# clang sets -fmerge-all-constants by default as optimization, but this
# is non-conforming behavior for C and in fact breaks the kernel, so we
# need to disable it here generally.
KBUILD_CFLAGS += $( call cc-option,-fno-merge-all-constants)
# for gcc -fno-merge-all-constants disables everything, but it is fine
# to have actual conforming behavior enabled.
KBUILD_CFLAGS += $( call cc-option,-fmerge-constants)
2017-12-30 04:34:43 +03:00
# Make sure -fstack-check isn't enabled (like gentoo apparently did)
KBUILD_CFLAGS += $( call cc-option,-fno-stack-check,)
2009-09-18 23:49:37 +04:00
# conserve stack if available
KBUILD_CFLAGS += $( call cc-option,-fconserve-stack)
2013-12-24 01:56:06 +04:00
# Prohibit date/time macros, which would make the build non-deterministic
KBUILD_CFLAGS += $( call cc-option,-Werror= date-time)
2016-03-08 11:29:09 +03:00
# enforce correct pointer usage
KBUILD_CFLAGS += $( call cc-option,-Werror= incompatible-pointer-types)
2017-03-21 03:14:11 +03:00
# Require designated initializers for all marked structures
KBUILD_CFLAGS += $( call cc-option,-Werror= designated-init)
2018-03-30 07:15:26 +03:00
# change __FILE__ to the relative path from the srctree
KBUILD_CFLAGS += $( call cc-option,-fmacro-prefix-map= $( srctree) /= )
2019-07-17 19:06:26 +03:00
# ensure -fcf-protection is disabled when using retpoline as it is
# incompatible with -mindirect-branch=thunk-extern
i f d e f C O N F I G _ R E T P O L I N E
KBUILD_CFLAGS += $( call cc-option,-fcf-protection= none)
e n d i f
2015-03-27 14:43:36 +03:00
i n c l u d e s c r i p t s / M a k e f i l e . k a s a n
i n c l u d e s c r i p t s / M a k e f i l e . e x t r a w a r n
2016-01-21 02:00:55 +03:00
i n c l u d e s c r i p t s / M a k e f i l e . u b s a n
2014-04-14 13:27:10 +04:00
2019-08-20 20:09:41 +03:00
# Add user supplied CPPFLAGS, AFLAGS and CFLAGS as the last assignments
KBUILD_CPPFLAGS += $( KCPPFLAGS)
KBUILD_AFLAGS += $( KAFLAGS)
KBUILD_CFLAGS += $( KCFLAGS)
2007-10-16 00:03:58 +04:00
2019-07-13 07:01:10 +03:00
KBUILD_LDFLAGS_MODULE += --build-id
LDFLAGS_vmlinux += --build-id
2007-07-19 12:48:40 +04:00
2009-03-04 22:59:07 +03:00
i f e q ( $( CONFIG_STRIP_ASM_SYMS ) , y )
2009-09-17 00:36:55 +04:00
LDFLAGS_vmlinux += $( call ld-option, -X,)
2009-03-04 22:59:07 +03:00
e n d i f
2019-08-01 04:18:42 +03:00
i f e q ( $( CONFIG_RELR ) , y )
LDFLAGS_vmlinux += --pack-dyn-relocs= relr
e n d i f
2018-05-28 21:27:35 +03:00
# insure the checker run with the right endianness
CHECKFLAGS += $( if $( CONFIG_CPU_BIG_ENDIAN) ,-mbig-endian,-mlittle-endian)
2018-05-30 23:48:38 +03:00
# the checker needs the correct machine size
CHECKFLAGS += $( if $( CONFIG_64BIT) ,-m64,-m32)
2005-04-17 02:20:36 +04:00
# Default kernel image to build when no specific target is given.
2006-06-25 02:07:55 +04:00
# KBUILD_IMAGE may be overruled on the command line or
2005-04-17 02:20:36 +04: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-02 03:56:28 +04: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-17 02:20:36 +04: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-25 02:07:55 +04:00
# makefile but the argument can be passed to make if needed.
2005-04-17 02:20:36 +04:00
#
2006-01-16 14:46:07 +03:00
MODLIB = $( INSTALL_MOD_PATH) /lib/modules/$( KERNELRELEASE)
2005-04-17 02:20:36 +04:00
export MODLIB
2006-06-22 04:53:09 +04:00
#
2014-04-28 11:32:43 +04:00
# INSTALL_MOD_STRIP, if defined, will cause modules to be
# stripped after they are installed. If INSTALL_MOD_STRIP is '1', then
# the default option --strip-debug will be used. Otherwise,
# INSTALL_MOD_STRIP value will be used as the options to the strip command.
2009-01-14 23:38:20 +03:00
2006-06-22 04:53:09 +04:00
i f d e f I N S T A L L _ M O D _ S T R I P
i f e q ( $( INSTALL_MOD_STRIP ) , 1 )
2009-01-14 23:38:20 +03:00
mod_strip_cmd = $( STRIP) --strip-debug
2006-06-22 04:53:09 +04:00
e l s e
2009-01-14 23:38:20 +03:00
mod_strip_cmd = $( STRIP) $( INSTALL_MOD_STRIP)
2006-06-22 04:53:09 +04:00
e n d i f # INSTALL_MOD_STRIP=1
e l s e
2009-01-14 23:38:20 +03:00
mod_strip_cmd = true
2006-06-22 04:53:09 +04:00
e n d i f # INSTALL_MOD_STRIP
export mod_strip_cmd
2014-08-27 15:01:56 +04:00
# CONFIG_MODULE_COMPRESS, if defined, will cause module to be compressed
# after they are installed in agreement with CONFIG_MODULE_COMPRESS_GZIP
# or CONFIG_MODULE_COMPRESS_XZ.
mod_compress_cmd = true
i f d e f C O N F I G _ M O D U L E _ C O M P R E S S
ifdef CONFIG_MODULE_COMPRESS_GZIP
2015-07-07 21:26:07 +03:00
mod_compress_cmd = gzip -n -f
2014-08-27 15:01:56 +04:00
endif # CONFIG_MODULE_COMPRESS_GZIP
ifdef CONFIG_MODULE_COMPRESS_XZ
2015-07-07 21:26:07 +03:00
mod_compress_cmd = xz -f
2014-08-27 15:01:56 +04:00
endif # CONFIG_MODULE_COMPRESS_XZ
e n d i f # CONFIG_MODULE_COMPRESS
export mod_compress_cmd
2013-01-25 07:11:31 +04:00
i f d e f C O N F I G _ M O D U L E _ S I G _ A L L
2015-08-14 18:17:16 +03:00
$( eval $ ( call config_filename ,MODULE_SIG_KEY ) )
mod_sign_cmd = scripts/sign-file $( CONFIG_MODULE_SIG_HASH) $( MODULE_SIG_KEY_SRCPREFIX) $( CONFIG_MODULE_SIG_KEY) certs/signing_key.x509
2012-10-19 05:23:15 +04:00
e l s e
mod_sign_cmd = true
e n d i f
export mod_sign_cmd
2019-03-26 20:48:39 +03:00
HOST_LIBELF_LIBS = $( shell pkg-config libelf --libs 2>/dev/null || echo -lelf)
2017-02-15 21:21:17 +03:00
i f d e f C O N F I G _ S T A C K _ V A L I D A T I O N
has_libelf := $( call try-run,\
2019-03-26 20:48:39 +03:00
echo "int main() {}" | $( HOSTCC) -xc -o /dev/null $( HOST_LIBELF_LIBS) -,1,0)
2017-02-15 21:21:17 +03:00
ifeq ( $( has_libelf) ,1)
objtool_target := tools/objtool FORCE
else
SKIP_STACK_VALIDATION := 1
export SKIP_STACK_VALIDATION
endif
e n d i f
2019-01-15 10:19:00 +03:00
PHONY += prepare0
2012-10-19 05:23:15 +04: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 18:19:18 +03:00
export MODORDER := $( extmod-prefix) modules.order
2019-08-02 13:23:58 +03:00
2005-04-17 02:20:36 +04:00
i f e q ( $( KBUILD_EXTMOD ) , )
2015-08-14 17:20:41 +03:00
core-y += kernel/ certs/ mm/ fs/ ipc/ security/ crypto/ block/
2005-04-17 02:20:36 +04:00
vmlinux-dirs := $( patsubst %/,%,$( filter %/, $( init-y) $( init-m) \
$( core-y) $( core-m) $( drivers-y) $( drivers-m) \
2015-09-22 11:47:29 +03:00
$( net-y) $( net-m) $( libs-y) $( libs-m) $( virt-y) ) )
2005-04-17 02:20:36 +04:00
2019-04-27 06:33:37 +03:00
vmlinux-alldirs := $( sort $( vmlinux-dirs) Documentation \
$( patsubst %/,%,$( filter %/, $( init-) $( core-) \
$( drivers-) $( net-) $( libs-) $( virt-) ) ) )
2005-04-17 02:20:36 +04:00
2019-08-10 18:53:04 +03:00
build-dirs := $( vmlinux-dirs)
2019-08-10 18:53:05 +03:00
clean-dirs := $( vmlinux-alldirs)
2019-08-10 18:53:04 +03:00
2018-02-10 17:25:04 +03:00
init-y := $( patsubst %/, %/built-in.a, $( init-y) )
core-y := $( patsubst %/, %/built-in.a, $( core-y) )
drivers-y := $( patsubst %/, %/built-in.a, $( drivers-y) )
net-y := $( patsubst %/, %/built-in.a, $( net-y) )
2005-04-17 02:20:36 +04:00
libs-y1 := $( patsubst %/, %/lib.a, $( libs-y) )
2018-02-10 17:25:04 +03:00
libs-y2 := $( patsubst %/, %/built-in.a, $( filter-out %.a, $( libs-y) ) )
virt-y := $( patsubst %/, %/built-in.a, $( virt-y) )
2005-04-17 02:20:36 +04:00
2012-05-05 12:18:41 +04:00
# Externally visible symbols (used by link-vmlinux.sh)
2019-01-17 03:10:04 +03:00
export KBUILD_VMLINUX_OBJS := $( head-y) $( init-y) $( core-y) $( libs-y2) \
$( drivers-y) $( net-y) $( virt-y)
2017-06-19 18:52:05 +03:00
export KBUILD_VMLINUX_LIBS := $( libs-y1)
2012-05-05 12:18:40 +04:00
export KBUILD_LDS := arch/$( SRCARCH) /kernel/vmlinux.lds
2012-05-05 12:18:41 +04:00
export LDFLAGS_vmlinux
2019-09-21 16:18:46 +03:00
# used by scripts/Makefile.package
2019-05-15 19:18:54 +03:00
export KBUILD_ALLDIRS := $( sort $( filter-out arch/%,$( vmlinux-alldirs) ) LICENSES arch include scripts tools)
2008-12-16 14:30:08 +03:00
2019-01-17 03:10:04 +03:00
vmlinux-deps := $( KBUILD_LDS) $( KBUILD_VMLINUX_OBJS) $( KBUILD_VMLINUX_LIBS)
2005-04-17 02:20:36 +04:00
2018-03-16 10:37:15 +03:00
# Recurse until adjust_autoksyms.sh is satisfied
PHONY += autoksyms_recursive
2016-04-22 22:25:00 +03:00
i f d e f C O N F I G _ T R I M _ U N U S E D _ K S Y M S
2019-08-10 18:53:04 +03:00
autoksyms_recursive : descend modules .order
2016-04-25 18:55:08 +03:00
$( Q) $( CONFIG_SHELL) $( srctree) /scripts/adjust_autoksyms.sh \
2016-12-02 23:11:50 +03:00
" $( MAKE) -f $( srctree) /Makefile vmlinux "
2016-04-22 22:25:00 +03:00
e n d i f
2016-01-27 05:50:18 +03:00
2018-03-16 10:37:13 +03: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.
# (this can be evaluated only once include/config/auto.conf has been included)
i f d e f C O N F I G _ T R I M _ U N U S E D _ K S Y M S
KBUILD_MODULES := 1
e n d i f
kbuild: restore autoksyms.h touch to the top Makefile
Commit d3fc425e819b ("kbuild: make sure autoksyms.h exists early")
moved the code that touches autoksyms.h to scripts/kconfig/Makefile
with obscure reason.
From Nicolas' comment [1], he did not seem to be sure about the root
cause.
I guess I figured it out, so here is a fix-up I think is more correct.
According to the error log in the original post [2], the build failed
in scripts/mod/devicetable-offsets.c
scripts/mod/Makefile is descended from scripts/Makefile, which is
invoked from the top-level Makefile by the 'scripts' target.
To build vmlinux and/or modules, Kbuild descend into $(vmlinux-dirs).
This depends on 'prepare' and 'scripts' as follows:
$(vmlinux-dirs): prepare scripts
Because there is no dependency between 'prepare' and 'scripts', the
parallel building can execute them simultaneously.
'prepare' depends on 'prepare1', which touched autoksyms.h, while
'scripts' descends into script/, then scripts/mod/, which needs
<generated/autoksyms.h> if CONFIG_TRIM_UNUSED_KSYMS. It was the
reason of the race.
I am not happy to have unrelated code in the Kconfig Makefile, so
getting it back to the top Makefile.
I removed the standalone test target because I want to use it to
create an empty autoksyms.h file. Here is a little improvement;
unnecessary autoksyms.h is not created when CONFIG_TRIM_UNUSED_KSYMS
is disabled.
[1] https://lkml.org/lkml/2016/11/30/734
[2] https://lkml.org/lkml/2016/11/30/531
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Nicolas Pitre <nico@linaro.org>
2018-03-16 10:37:12 +03:00
autoksyms_h := $( if $( CONFIG_TRIM_UNUSED_KSYMS) , include/generated/autoksyms.h)
$(autoksyms_h) :
$( Q) mkdir -p $( dir $@ )
$( Q) touch $@
2016-01-27 05:50:18 +03:00
2016-08-24 15:29:21 +03:00
ARCH_POSTLINK := $( wildcard $( srctree) /arch/$( SRCARCH) /Makefile.postlink)
# Final link of vmlinux with optional arch pass after final link
2017-08-02 05:31:06 +03:00
cmd_link-vmlinux = \
2018-08-24 02:20:39 +03:00
$( CONFIG_SHELL) $< $( LD) $( KBUILD_LDFLAGS) $( LDFLAGS_vmlinux) ; \
2016-08-24 15:29:21 +03:00
$( if $( ARCH_POSTLINK) , $( MAKE) -f $( ARCH_POSTLINK) $@ , true )
2016-04-22 22:25:00 +03:00
2018-03-16 10:37:15 +03:00
vmlinux : scripts /link -vmlinux .sh autoksyms_recursive $( vmlinux -deps ) FORCE
2012-05-05 12:18:41 +04:00
+$( call if_changed,link-vmlinux)
2007-07-17 12:54:06 +04: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 04:05:22 +03:00
targets := vmlinux
2014-04-28 11:26:18 +04:00
# The actual objects are generated when descending,
2005-04-17 02:20:36 +04:00
# make sure no implicit rule kicks in
2019-08-10 18:53:04 +03:00
$(sort $(vmlinux-deps)) : descend ;
2005-04-17 02:20:36 +04:00
2019-01-03 04:16:54 +03:00
filechk_kernel.release = \
2013-07-11 17:34:51 +04:00
echo " $( KERNELVERSION) $$ ( $( CONFIG_SHELL) $( srctree) /scripts/setlocalversion $( srctree) ) "
2013-06-28 13:27:31 +04:00
# Store (new) KERNELRELEASE string in include/config/kernel.release
2019-04-07 13:03:18 +03:00
include/config/kernel.release : FORCE
2013-07-11 17:34:51 +04:00
$( call filechk,kernel.release)
2006-01-09 23:20:34 +03:00
2018-03-16 10:37:11 +03: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 06:13:24 +03:00
scripts : scripts_basic scripts_dtc
2018-03-16 10:37:11 +03:00
$( Q) $( MAKE) $( build) = $( @)
2006-01-09 23:20:34 +03:00
2005-04-17 02:20:36 +04:00
# Things we need to do before we recursively start building the kernel
2005-09-12 00:30:22 +04: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-17 02:20:36 +04:00
2019-08-22 07:46:12 +03:00
PHONY += prepare archprepare
2005-09-12 00:30:22 +04:00
2019-08-22 07:46:13 +03:00
archprepare : outputmakefile archheaders archscripts scripts include /config /kernel .release \
2019-07-17 09:17:59 +03:00
asm-generic $( version_h) $( autoksyms_h) include/generated/utsrelease.h
2005-09-12 00:30:22 +04:00
2018-11-29 05:58:50 +03:00
prepare0 : archprepare
2018-11-29 06:13:24 +03:00
$( Q) $( MAKE) $( build) = scripts/mod
2005-09-10 23:05:36 +04:00
$( Q) $( MAKE) $( build) = .
2005-09-09 21:28:28 +04:00
2005-04-17 02:20:36 +04:00
# All the preparing..
2016-02-29 07:22:42 +03:00
prepare : prepare 0 prepare -objtool
2017-10-04 06:56:06 +03:00
# Support for using generic headers in asm-generic
2018-12-05 14:28:04 +03:00
asm-generic := -f $( srctree) /scripts/Makefile.asm-generic obj
2017-10-04 06:56:06 +03:00
PHONY += asm-generic uapi-asm-generic
asm-generic : uapi -asm -generic
2019-03-17 05:01:09 +03:00
$( Q) $( MAKE) $( asm-generic) = arch/$( SRCARCH) /include/generated/asm \
generic = include/asm-generic
2017-10-04 06:56:06 +03:00
uapi-asm-generic :
2019-03-17 05:01:09 +03:00
$( Q) $( MAKE) $( asm-generic) = arch/$( SRCARCH) /include/generated/uapi/asm \
generic = include/uapi/asm-generic
2017-10-04 06:56:06 +03:00
2016-02-29 07:22:42 +03:00
PHONY += prepare-objtool
2016-03-03 20:39:30 +03:00
prepare-objtool : $( objtool_target )
2018-12-18 08:25:41 +03:00
i f e q ( $( SKIP_STACK_VALIDATION ) , 1 )
i f d e f C O N F I G _ U N W I N D E R _ O R C
@echo "error: Cannot generate ORC metadata for CONFIG_UNWINDER_ORC=y, please install libelf-dev, libelf-devel or elfutils-libelf-devel" >& 2
@false
e l s e
@echo "warning: Cannot use CONFIG_STACK_VALIDATION=y, please install libelf-dev, libelf-devel or elfutils-libelf-devel" >& 2
e n d i f
e n d i f
2005-04-17 02:20:36 +04: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-04 01:30:54 +04:00
d e f i n e f i l e c h k _ u t s r e l e a s e . h
if [ ` echo -n " $( KERNELRELEASE) " | wc -c ` -gt $( uts_len) ] ; then \
echo '"$(KERNELRELEASE)" exceeds $(uts_len) characters' >& 2; \
exit 1; \
fi ; \
2018-12-31 11:24:09 +03:00
echo \# define UTS_RELEASE \" $( KERNELRELEASE) \"
2006-07-04 01:30:54 +04:00
e n d e f
2005-04-17 02:20:36 +04:00
d e f i n e f i l e c h k _ v e r s i o n . h
2018-12-31 11:24:09 +03:00
echo \# define LINUX_VERSION_CODE $( shell \
2012-02-17 01:49:15 +04:00
expr $( VERSION) \* 65536 + 0$( PATCHLEVEL) \* 256 + 0$( SUBLEVEL) ) ; \
2018-12-31 11:24:09 +03:00
echo '#define KERNEL_VERSION(a,b,c) (((a) << 16) + ((b) << 8) + (c))'
2005-04-17 02:20:36 +04:00
e n d e f
2018-07-25 08:16:11 +03:00
$(version_h) : FORCE
2005-04-17 02:20:36 +04:00
$( call filechk,version.h)
2014-11-27 18:13:17 +03:00
$( Q) rm -f $( old_version_h)
2005-04-17 02:20:36 +04:00
2009-10-18 02:52:28 +04:00
include/generated/utsrelease.h : include /config /kernel .release FORCE
2006-07-04 01:30:54 +04:00
$( call filechk,utsrelease.h)
2008-12-16 14:33:43 +03:00
PHONY += headerdep
headerdep :
2011-04-27 01:17:11 +04:00
$( Q) find $( srctree) /include/ -name '*.h' | xargs --max-args 1 \
$( srctree) /scripts/headerdep.pl -I$( srctree) /include
2008-12-16 14:33:43 +03:00
2006-06-18 14:58:39 +04:00
# ---------------------------------------------------------------------------
# Kernel headers
2008-06-05 18:43:46 +04:00
#Default location for installed headers
export INSTALL_HDR_PATH = $( objtree) /usr
2006-09-25 01:16:03 +04: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 13:14:02 +03: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 18:43:46 +04:00
2006-06-18 14:58:39 +04: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 13:14:02 +03:00
headers_install : headers
$( call cmd,headers_install)
2012-05-08 22:22:24 +04: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 13:14:02 +03:00
PHONY += archheaders archscripts
2008-06-05 18:43:46 +04:00
2019-06-04 13:14:04 +03:00
hdr-inst := -f $( srctree) /scripts/Makefile.headersinst obj
2006-09-25 01:16:03 +04: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 13:14:02 +03:00
PHONY += headers
headers : $( version_h ) scripts_unifdef uapi -asm -generic archheaders archscripts
2017-10-04 06:56:04 +03:00
$( if $( wildcard $( srctree) /arch/$( SRCARCH) /include/uapi/asm/Kbuild) ,, \
2012-10-02 21:01:57 +04:00
$( error Headers not exportable for the $( SRCARCH) architecture) )
2019-06-04 13:14:03 +03:00
$( Q) $( MAKE) $( hdr-inst) = include/uapi
$( Q) $( MAKE) $( hdr-inst) = arch/$( SRCARCH) /include/uapi
2007-02-14 11:33:02 +03:00
2006-06-18 15:02:10 +04:00
PHONY += headers_check
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 13:14:02 +03:00
headers_check : headers
2019-06-04 13:14:03 +03:00
$( Q) $( MAKE) $( hdr-inst) = include/uapi HDRCHECK = 1
$( Q) $( MAKE) $( hdr-inst) = arch/$( SRCARCH) /include/uapi HDRCHECK = 1
2006-06-18 15:02:10 +04:00
2019-06-04 13:13:59 +03:00
i f d e f C O N F I G _ H E A D E R S _ I N S T A L L
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 13:14:02 +03:00
prepare : headers
2019-06-04 13:13:59 +03:00
e n d i f
2006-06-18 15:02:10 +04:00
2018-12-05 10:38:35 +03:00
i f d e f C O N F I G _ H E A D E R S _ C H E C K
all : headers_check
e n d i f
2019-06-04 13:14:01 +03:00
PHONY += scripts_unifdef
scripts_unifdef : scripts_basic
$( Q) $( MAKE) $( build) = scripts scripts/unifdef
2014-08-07 23:07:46 +04:00
# ---------------------------------------------------------------------------
# Kernel selftest
PHONY += kselftest
kselftest :
2017-09-07 01:44:35 +03:00
$( Q) $( MAKE) -C $( srctree) /tools/testing/selftests run_tests
2014-08-07 23:07:46 +04:00
2019-09-27 01:40:14 +03:00
kselftest-% : FORCE
$( Q) $( MAKE) -C $( srctree) /tools/testing/selftests $*
2015-10-08 05:41:18 +03:00
2016-01-08 10:27:34 +03:00
PHONY += kselftest-merge
kselftest-merge :
$( if $( wildcard $( objtree) /.config) ,, $( error No .config exists, config your kernel first!) )
2019-05-20 18:16:14 +03:00
$( Q) find $( srctree) /tools/testing/selftests -name config | \
xargs $( srctree) /scripts/kconfig/merge_config.sh -m $( objtree) /.config
2019-08-21 10:03:48 +03:00
$( Q) $( MAKE) -f $( srctree) /Makefile olddefconfig
2016-01-08 10:27:34 +03:00
2018-01-11 00:19:37 +03:00
# ---------------------------------------------------------------------------
# Devicetree files
i f n e q ( $( wildcard $ ( srctree ) /arch /$ ( SRCARCH ) /boot /dts /) , )
dtstree := arch/$( SRCARCH) /boot/dts
e n d i f
i f n e q ( $( dtstree ) , )
2019-08-22 07:46:12 +03:00
%.dtb : include /config /kernel .release scripts_dtc
2018-01-11 00:19:37 +03:00
$( Q) $( MAKE) $( build) = $( dtstree) $( dtstree) /$@
2018-09-06 21:26:07 +03:00
PHONY += dtbs dtbs_install dt_binding_check
2019-08-22 07:46:12 +03:00
dtbs dtbs_check : include /config /kernel .release scripts_dtc
2018-01-11 00:19:37 +03:00
$( Q) $( MAKE) $( build) = $( dtstree)
2018-09-06 21:26:07 +03:00
dtbs_check : export CHECK_DTBS =1
dtbs_check : dt_binding_check
2018-01-11 00:19:37 +03:00
dtbs_install :
$( Q) $( MAKE) $( dtbinst) = $( dtstree)
i f d e f C O N F I G _ O F _ E A R L Y _ F L A T T R E E
all : dtbs
e n d i f
e n d i f
PHONY += scripts_dtc
scripts_dtc : scripts_basic
$( Q) $( MAKE) $( build) = scripts/dtc
2018-09-06 21:26:07 +03:00
dt_binding_check : scripts_dtc
$( Q) $( MAKE) $( build) = Documentation/devicetree/bindings
2005-04-17 02:20:36 +04:00
# ---------------------------------------------------------------------------
# Modules
i f d e f C O N F I G _ M O D U L E S
2006-06-25 02:07:55 +04:00
# By default, build modules as well
2005-04-17 02:20:36 +04:00
2010-03-10 14:28:58 +03:00
all : modules
2005-04-17 02:20:36 +04:00
2014-04-28 11:32:43 +04:00
# Build modules
2007-12-07 15:04:30 +03:00
#
2014-04-28 11:32:43 +04:00
# A module can be listed more than once in obj-m resulting in
# duplicate lines in modules.order files. Those are removed
# using awk while concatenating to the final file.
2005-04-17 02:20:36 +04:00
2006-03-06 01:14:10 +03:00
PHONY += modules
2019-06-23 19:13:28 +03:00
modules : $( if $ ( KBUILD_BUILTIN ) ,vmlinux ) modules .order modules .builtin
2006-08-08 23:36:08 +04:00
$( Q) $( MAKE) -f $( srctree) /scripts/Makefile.modpost
2019-05-17 19:07:15 +03:00
$( Q) $( CONFIG_SHELL) $( srctree) /scripts/modules-check.sh
2005-04-17 02:20:36 +04:00
2019-08-10 18:53:04 +03:00
modules.order : descend
$( Q) $( AWK) '!x[$$0]++' $( addsuffix /$@ , $( build-dirs) ) > $@
2019-06-23 19:13:28 +03:00
2019-08-10 18:53:04 +03:00
modbuiltin-dirs := $( addprefix _modbuiltin_, $( build-dirs) )
2010-03-08 12:07:12 +03:00
2019-06-23 19:13:27 +03:00
modules.builtin : $( modbuiltin -dirs )
2019-08-10 18:53:04 +03:00
$( Q) $( AWK) '!x[$$0]++' $( addsuffix /$@ , $( build-dirs) ) > $@
2010-03-08 12:07:12 +03:00
2019-06-23 19:13:27 +03:00
PHONY += $( modbuiltin-dirs)
# tristate.conf is not included from this Makefile. Add it as a prerequisite
# here to make it self-healing in case somebody accidentally removes it.
$(modbuiltin-dirs) : include /config /tristate .conf
$( Q) $( MAKE) $( modbuiltin) = $( patsubst _modbuiltin_%,%,$@ )
2005-04-17 02:20:36 +04:00
# Target to prepare building external modules
2006-03-06 01:14:10 +03:00
PHONY += modules_prepare
2018-11-29 06:56:30 +03:00
modules_prepare : prepare
2005-04-17 02:20:36 +04:00
# Target to install modules
2006-03-06 01:14:10 +03:00
PHONY += modules_install
2005-04-17 02:20:36 +04:00
modules_install : _modinst_ _modinst_post
2006-03-06 01:14:10 +03:00
PHONY += _modinst_
2010-06-08 00:22:12 +04:00
_modinst_ :
2005-04-17 02:20:36 +04:00
@rm -rf $( MODLIB) /kernel
@rm -f $( MODLIB) /source
@mkdir -p $( MODLIB) /kernel
2017-08-20 09:04:11 +03:00
@ln -s $( abspath $( srctree) ) $( MODLIB) /source
2005-04-17 02:20:36 +04:00
@if [ ! $( objtree) -ef $( MODLIB) /build ] ; then \
rm -f $( MODLIB) /build ; \
2014-04-25 19:29:45 +04:00
ln -s $( CURDIR) $( MODLIB) /build ; \
2005-04-17 02:20:36 +04:00
fi
2019-07-17 09:17:50 +03:00
@sed 's:^:kernel/:' modules.order > $( MODLIB) /modules.order
@sed 's:^:kernel/:' modules.builtin > $( MODLIB) /modules.builtin
2019-04-29 19:11:14 +03:00
@cp -f $( objtree) /modules.builtin.modinfo $( MODLIB) /
2006-08-08 23:36:08 +04:00
$( Q) $( MAKE) -f $( srctree) /scripts/Makefile.modinst
2005-04-17 02:20:36 +04:00
2007-10-18 23:24:21 +04:00
# This depmod is only for convenience to give the initial
2005-04-17 02:20:36 +04:00
# boot a modules.dep even before / is mounted read-write. However the
# boot script depmod is the master version.
2006-03-06 01:14:10 +03:00
PHONY += _modinst_post
2013-07-11 06:02:51 +04:00
_modinst_post : _modinst_
2007-10-18 23:24:21 +04:00
$( call cmd,depmod)
2005-04-17 02:20:36 +04:00
2012-11-05 02:39:24 +04:00
i f e q ( $( CONFIG_MODULE_SIG ) , y )
PHONY += modules_sign
modules_sign :
$( Q) $( MAKE) -f $( srctree) /scripts/Makefile.modsign
e n d i f
2005-04-17 02:20:36 +04:00
e l s e # CONFIG_MODULES
# Modules not configured
# ---------------------------------------------------------------------------
2016-03-13 03:39:22 +03:00
PHONY += modules modules_install
modules modules_install :
2012-07-08 01:04:40 +04:00
@echo >& 2
@echo >& 2 "The present kernel configuration has modules disabled."
@echo >& 2 "Type 'make config' and enable loadable module support."
@echo >& 2 "Then build a kernel with module support enabled."
@echo >& 2
2005-04-17 02:20:36 +04:00
@exit 1
e n d i f # CONFIG_MODULES
###
# 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'
kbuild: create *.mod with full directory path and remove MODVERDIR
While descending directories, Kbuild produces objects for modules,
but do not link final *.ko files; it is done in the modpost.
To keep track of modules, Kbuild creates a *.mod file in $(MODVERDIR)
for every module it is building. Some post-processing steps read the
necessary information from *.mod files. This avoids descending into
directories again. This mechanism was introduced in 2003 or so.
Later, commit 551559e13af1 ("kbuild: implement modules.order") added
modules.order. So, we can simply read it out to know all the modules
with directory paths. This is easier than parsing the first line of
*.mod files.
$(MODVERDIR) has a flat directory structure, that is, *.mod files
are named only with base names. This is based on the assumption that
the module name is unique across the tree. This assumption is really
fragile.
Stephen Rothwell reported a race condition caused by a module name
conflict:
https://lkml.org/lkml/2019/5/13/991
In parallel building, two different threads could write to the same
$(MODVERDIR)/*.mod simultaneously.
Non-unique module names are the source of all kind of troubles, hence
commit 3a48a91901c5 ("kbuild: check uniqueness of module names")
introduced a new checker script.
However, it is still fragile in the build system point of view because
this race happens before scripts/modules-check.sh is invoked. If it
happens again, the modpost will emit unclear error messages.
To fix this issue completely, create *.mod with full directory path
so that two threads never attempt to write to the same file.
$(MODVERDIR) is no longer needed.
Since modules with directory paths are listed in modules.order, Kbuild
is still able to find *.mod files without additional descending.
I also killed cmd_secanalysis; scripts/mod/sumversion.c computes MD4 hash
for modules with MODULE_VERSION(). When CONFIG_DEBUG_SECTION_MISMATCH=y,
it occurs not only in the modpost stage, but also during directory
descending, where sumversion.c may parse stale *.mod files. It would emit
'No such file or directory' warning when an object consisting a module is
renamed, or when a single-obj module is turned into a multi-obj module or
vice versa.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Nicolas Pitre <nico@fluxnic.net>
2019-07-17 09:17:57 +03:00
CLEAN_DIRS += include/ksym
2019-04-29 19:11:14 +03:00
CLEAN_FILES += modules.builtin.modinfo
2005-04-17 02:20:36 +04:00
# Directories & files removed with 'make mrproper'
kbuild: compile-test exported headers to ensure they are self-contained
Multiple people have suggested compile-testing UAPI headers to ensure
they can be really included from user-space. "make headers_check" is
obviously not enough to catch bugs, and we often leak unresolved
references to user-space.
Use the new header-test-y syntax to implement it. Please note exported
headers are compile-tested with a completely different set of compiler
flags. The header search path is set to $(objtree)/usr/include since
exported headers should not include unexported ones.
We use -std=gnu89 for the kernel space since the kernel code highly
depends on GNU extensions. On the other hand, UAPI headers should be
written in more standardized C, so they are compiled with -std=c90.
This will emit errors if C++ style comments, the keyword 'inline', etc.
are used. Please use C style comments (/* ... */), '__inline__', etc.
in UAPI headers.
There is additional compiler requirement to enable this test because
many of UAPI headers include <stdlib.h>, <sys/ioctl.h>, <sys/time.h>,
etc. directly or indirectly. You cannot use kernel.org pre-built
toolchains [1] since they lack <stdlib.h>.
I reused CONFIG_CC_CAN_LINK to check the system header availability.
The intention is slightly different, but a compiler that can link
userspace programs provide system headers.
For now, a lot of headers need to be excluded because they cannot
be compiled standalone, but this is a good start point.
[1] https://mirrors.edge.kernel.org/pub/tools/crosstool/index.html
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
2019-07-01 03:58:40 +03:00
MRPROPER_DIRS += include/config include/generated \
2019-08-21 10:02:02 +03:00
arch/$( SRCARCH) /include/generated .tmp_objdiff \
debian/ snap/ tar-install/
2017-09-22 08:31:13 +03:00
MRPROPER_FILES += .config .config.old .version \
2019-07-15 17:01:49 +03:00
Module.symvers \
2015-07-20 23:16:30 +03:00
signing_key.pem signing_key.priv signing_key.x509 \
x509.genkey extra_certificates signing_key.x509.keyid \
2019-08-21 10:02:02 +03:00
signing_key.x509.signer vmlinux-gdb.py \
*.spec
2005-04-17 02:20:36 +04:00
2019-07-15 17:01:49 +03:00
# Directories & files removed with 'make distclean'
DISTCLEAN_DIRS +=
DISTCLEAN_FILES += tags TAGS cscope* GPATH GTAGS GRTAGS GSYMS
2005-04-17 02:20:36 +04:00
# clean - Delete most, but leave enough to build external modules
#
clean : rm -dirs := $( CLEAN_DIRS )
clean : rm -files := $( CLEAN_FILES )
2019-08-10 18:53:05 +03:00
PHONY += archclean vmlinuxclean
2005-04-17 02:20:36 +04:00
2012-10-29 15:23:02 +04:00
vmlinuxclean :
$( Q) $( CONFIG_SHELL) $( srctree) /scripts/link-vmlinux.sh clean
2016-08-24 15:29:21 +03:00
$( Q) $( if $( ARCH_POSTLINK) , $( MAKE) -f $( ARCH_POSTLINK) clean)
2012-10-29 15:23:02 +04:00
clean : archclean vmlinuxclean
2005-04-17 02:20:36 +04:00
# mrproper - Delete all generated files, including .config
#
mrproper : rm -dirs := $( wildcard $ ( MRPROPER_DIRS ) )
mrproper : rm -files := $( wildcard $ ( MRPROPER_FILES ) )
2017-05-14 17:50:01 +03:00
mrproper-dirs := $( addprefix _mrproper_,scripts)
2005-04-17 02:20:36 +04:00
2019-01-14 11:29:29 +03:00
PHONY += $( mrproper-dirs) mrproper
2005-04-17 02:20:36 +04:00
$(mrproper-dirs) :
$( Q) $( MAKE) $( clean) = $( patsubst _mrproper_%,%,$@ )
2019-01-14 11:29:29 +03:00
mrproper : clean $( mrproper -dirs )
2005-04-17 02:20:36 +04:00
$( call cmd,rmdirs)
$( call cmd,rmfiles)
# distclean
#
2019-07-15 17:01:49 +03:00
distclean : rm -dirs := $( wildcard $ ( DISTCLEAN_DIRS ) )
distclean : rm -files := $( wildcard $ ( DISTCLEAN_FILES ) )
2006-03-06 01:14:10 +03:00
PHONY += distclean
2005-04-17 02:20:36 +04:00
distclean : mrproper
2019-07-15 17:01:49 +03:00
$( call cmd,rmdirs)
$( call cmd,rmfiles)
2005-04-17 02:20:36 +04:00
@find $( srctree) $( RCS_FIND_IGNORE) \
2006-06-25 02:07:55 +04:00
\( -name '*.orig' -o -name '*.rej' -o -name '*~' \
2017-01-22 17:02:32 +03:00
-o -name '*.bak' -o -name '#*#' -o -name '*%' \
-o -name 'core' \) \
2005-04-17 02:20:36 +04:00
-type f -print | xargs rm -f
# Packaging of the kernel to various formats
# ---------------------------------------------------------------------------
2010-06-07 14:44:25 +04:00
%src-pkg : FORCE
2019-08-21 10:02:04 +03:00
$( Q) $( MAKE) -f $( srctree) /scripts/Makefile.package $@
2006-06-09 09:12:37 +04:00
%pkg : include /config /kernel .release FORCE
2019-08-21 10:02:04 +03:00
$( Q) $( MAKE) -f $( srctree) /scripts/Makefile.package $@
2005-04-17 02:20:36 +04:00
# Brief documentation of the typical targets used
# ---------------------------------------------------------------------------
2008-04-07 00:16:07 +04:00
boards := $( wildcard $( srctree) /arch/$( SRCARCH) /configs/*_defconfig)
2014-10-28 16:18:20 +03:00
boards := $( sort $( notdir $( boards) ) )
2008-04-07 00:16:07 +04:00
board-dirs := $( dir $( wildcard $( srctree) /arch/$( SRCARCH) /configs/*/*_defconfig) )
board-dirs := $( sort $( notdir $( board-dirs:/= ) ) )
2005-04-17 02:20:36 +04:00
2016-03-13 03:39:55 +03:00
PHONY += help
2005-04-17 02:20:36 +04:00
help :
@echo 'Cleaning targets:'
2006-12-12 21:09:40 +03:00
@echo ' clean - Remove most generated files but keep the config and'
2006-09-24 16:01:08 +04:00
@echo ' enough build support to build external modules'
2006-12-12 21:09:40 +03:00
@echo ' mrproper - Remove all generated files + config + various backup files'
2006-09-24 16:01:08 +04:00
@echo ' distclean - mrproper + remove editor backup and patch files'
2005-04-17 02:20:36 +04:00
@echo ''
@echo 'Configuration targets:'
@$( 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 22:11:34 +03:00
@echo ' modules_install - Install all modules to INSTALL_MOD_PATH (default: /)'
2005-04-17 02:20:36 +04:00
@echo ' dir/ - Build all files in dir and below'
2015-12-10 19:35:19 +03:00
@echo ' dir/file.[ois] - Build specified target only'
2017-04-24 23:04:58 +03:00
@echo ' dir/file.ll - Build the LLVM assembly file'
@echo ' (requires compiler support for LLVM assembly generation)'
2010-01-13 20:31:44 +03: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 04:56:08 +04:00
@echo ' dir/file.ko - Build module including final link'
2009-04-24 20:35:23 +04:00
@echo ' modules_prepare - Set up for building external modules'
2005-04-17 02:20:36 +04:00
@echo ' tags/TAGS - Generate tags file for editors'
@echo ' cscope - Generate cscope index'
2011-01-14 15:07:05 +03:00
@echo ' gtags - Generate GNU GLOBAL index'
2014-07-11 17:57:24 +04: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-21 02:24:17 +04:00
@echo ' headers_install - Install sanitised kernel headers to INSTALL_HDR_PATH' ; \
2007-01-29 15:47:01 +03:00
echo ' (default: $(INSTALL_HDR_PATH))' ; \
2008-06-21 02:24:17 +04:00
echo ''
2017-05-09 01:55:08 +03:00
@echo 'Static analysers:'
2005-04-17 02:20:36 +04:00
@echo ' checkstack - Generate a list of stack hogs'
@echo ' namespacecheck - Name space analysis on compiled kernel'
2007-11-14 23:34:55 +03:00
@echo ' versioncheck - Sanity check on version.h usage'
2007-11-04 23:01:55 +03:00
@echo ' includecheck - Check for duplicate included header files'
2007-08-25 01:04:56 +04:00
@echo ' export_report - List the usages of all exported symbols'
2008-12-16 14:33:43 +03:00
@echo ' headers_check - Sanity check on exported headers'
2010-06-06 19:15:01 +04:00
@echo ' headerdep - Detect inclusion cycles in headers'
2017-11-14 12:47:20 +03:00
@echo ' coccicheck - Check with Coccinelle'
2010-06-06 19:15:01 +04:00
@echo ''
2019-09-06 13:32:32 +03:00
@echo 'Tools:'
@echo ' nsdeps - Generate missing symbol namespace dependencies'
@echo ''
2017-05-09 01:55:08 +03:00
@echo 'Kernel selftest:'
2014-08-07 23:07:46 +04:00
@echo ' kselftest - Build and run kernel selftest (run as root)'
@echo ' Build, install, and boot kernel before'
@echo ' running kselftest on it'
2015-10-08 05:41:18 +03:00
@echo ' kselftest-clean - Remove all generated kselftest files'
2017-10-07 03:17:52 +03:00
@echo ' kselftest-merge - Merge all the config dependencies of kselftest to existing'
2016-01-08 10:27:34 +03:00
@echo ' .config.'
2014-08-07 23:07:46 +04:00
@echo ''
2018-01-11 00:19:37 +03:00
@$( if $( dtstree) , \
echo 'Devicetree:' ; \
2019-08-13 21:38:25 +03: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' ; \
echo ' dtbs_check - Validate device tree source files' ; \
2018-01-11 00:19:37 +03:00
echo '' )
2017-05-09 01:55:08 +03:00
@echo 'Userspace tools targets:'
@echo ' use "make tools/help"'
@echo ' or "cd tools; make help"'
@echo ''
2005-04-17 02:20:36 +04:00
@echo 'Kernel packaging:'
2019-08-21 10:02:04 +03:00
@$( MAKE) -f $( srctree) /scripts/Makefile.package help
2005-04-17 02:20:36 +04:00
@echo ''
@echo 'Documentation targets:'
2017-05-14 17:50:01 +03:00
@$( MAKE) -f $( srctree) /Documentation/Makefile dochelp
2005-04-17 02:20:36 +04:00
@echo ''
2008-04-26 06:34:58 +04:00
@echo 'Architecture specific targets ($(SRCARCH)):'
2005-04-17 02:20:36 +04:00
@$( if $( archhelp) ,$( archhelp) ,\
2008-04-26 06:34:58 +04:00
echo ' No architecture specific help defined for $(SRCARCH)' )
2005-04-17 02:20:36 +04:00
@echo ''
@$( if $( boards) , \
$( foreach b, $( boards) , \
printf " %-24s - Build for %s\\n" $( b) $( subst _defconfig,,$( b) ) ; ) \
echo '' )
2008-04-07 00:16:07 +04: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-17 02:20:36 +04:00
@echo ' make V=0|1 [targets] 0 => quiet build (default), 1 => verbose build'
2006-08-08 23:35:14 +04:00
@echo ' make V=2 [targets] 2 => give reason for rebuild of target'
2005-04-17 02:20:36 +04:00
@echo ' make O=dir [targets] Locate all output files in "dir", including .config'
2017-06-06 12:07:53 +03:00
@echo ' make C=1 [targets] Check re-compiled c source with $$CHECK (sparse by default)'
2006-05-24 00:57:23 +04:00
@echo ' make C=2 [targets] Force check of all c source with $$CHECK'
2011-06-16 15:26:23 +04:00
@echo ' make RECORDMCOUNT_WARN=1 [targets] Warn about ignored mcount sections'
2019-08-31 19:25:55 +03:00
@echo ' make W=n [targets] Enable extra build checks, n=1,2,3 where'
2011-04-28 00:15:27 +04: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'
2011-04-29 16:45:31 +04:00
@echo ' Multiple levels can be combined with W=12 or W=123'
2005-04-17 02:20:36 +04:00
@echo ''
@echo 'Execute "make" or "make all" to build all targets marked with [*] '
@echo 'For further info see the ./README file'
2008-04-07 00:16:07 +04:00
help-board-dirs := $( addprefix help-,$( board-dirs) )
help-boards : $( help -board -dirs )
2014-11-28 15:31:43 +03:00
boards-per-dir = $( sort $( notdir $( wildcard $( srctree) /arch/$( SRCARCH) /configs/$* /*_defconfig) ) )
2008-04-07 00:16:07 +04:00
$(help-board-dirs) : help -%:
@echo 'Architecture specific targets ($(SRCARCH) $*):'
@$( if $( boards-per-dir) , \
$( foreach b, $( boards-per-dir) , \
printf " %-24s - Build for %s\\n" $* /$( b) $( subst _defconfig,,$( b) ) ; ) \
echo '' )
2005-04-17 02:20:36 +04:00
# Documentation targets
# ---------------------------------------------------------------------------
2017-10-09 18:26:15 +03:00
DOC_TARGETS := xmldocs latexdocs pdfdocs htmldocs epubdocs cleandocs \
linkcheckdocs dochelp refcheckdocs
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 15:14:05 +03:00
PHONY += $( DOC_TARGETS)
2019-08-21 20:33:21 +03:00
$(DOC_TARGETS) :
2017-05-14 17:50:01 +03:00
$( Q) $( MAKE) $( build) = Documentation $@
2005-04-17 02:20:36 +04:00
2019-02-19 12:33:02 +03:00
# Misc
# ---------------------------------------------------------------------------
PHONY += scripts_gdb
2019-06-04 13:13:57 +03:00
scripts_gdb : prepare 0
2019-02-19 12:33:04 +03:00
$( Q) $( MAKE) $( build) = scripts/gdb
2019-02-19 12:33:05 +03:00
$( Q) ln -fsn $( abspath $( srctree) /scripts/gdb/vmlinux-gdb.py)
2019-02-19 12:33:02 +03:00
i f d e f C O N F I G _ G D B _ S C R I P T S
all : scripts_gdb
e n d i f
2005-04-17 02:20:36 +04:00
e l s e # KBUILD_EXTMOD
###
# 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
# in the basis kernel ordinary make commands (without M=...) must
# be used.
#
# The following are the only valid targets when building external
# modules.
# make M=dir clean Delete all automatically generated files
# make M=dir modules Make all modules in specified dir
# make M=dir Same as 'make M=dir modules'
# make M=dir modules_install
2006-06-25 02:07:55 +04:00
# Install the modules built in the module directory
2005-04-17 02:20:36 +04:00
# Assumes install directory is already created
# We are always building modules
KBUILD_MODULES := 1
2006-03-06 01:14:10 +03:00
PHONY += $( objtree) /Module.symvers
2005-04-17 02:20:36 +04:00
$(objtree)/Module.symvers :
@test -e $( objtree) /Module.symvers || ( \
echo; \
echo " WARNING: Symbol version dump $( objtree) /Module.symvers " ; \
echo " is missing; modules will have no dependencies and modversions." ; \
echo )
2019-08-10 18:53:04 +03:00
build-dirs := $( KBUILD_EXTMOD)
PHONY += modules
modules : descend $( objtree ) /Module .symvers
2006-08-08 23:36:08 +04:00
$( Q) $( MAKE) -f $( srctree) /scripts/Makefile.modpost
2005-04-17 02:20:36 +04:00
2006-03-06 01:14:10 +03:00
PHONY += modules_install
2006-01-29 01:51:57 +03:00
modules_install : _emodinst_ _emodinst_post
2006-02-14 17:58:15 +03:00
2006-03-06 01:14:10 +03:00
install-dir := $( if $( INSTALL_MOD_DIR) ,$( INSTALL_MOD_DIR) ,extra)
PHONY += _emodinst_
2006-01-29 01:51:57 +03:00
_emodinst_ :
$( Q) mkdir -p $( MODLIB) /$( install-dir)
2006-08-08 23:36:08 +04:00
$( Q) $( MAKE) -f $( srctree) /scripts/Makefile.modinst
2005-04-17 02:20:36 +04:00
2006-03-06 01:14:10 +03:00
PHONY += _emodinst_post
2006-01-29 01:51:57 +03:00
_emodinst_post : _emodinst_
$( call cmd,depmod)
2019-08-10 18:53:05 +03:00
clean-dirs := $( KBUILD_EXTMOD)
2010-09-06 14:00:08 +04:00
clean : rm -files := $( KBUILD_EXTMOD ) /Module .symvers
2005-04-17 02:20:36 +04:00
2019-08-10 18:53:00 +03:00
PHONY += /
/ :
@echo >& 2 '"$(MAKE) /" is no longer supported. Please use "$(MAKE) ./" instead.'
2016-03-13 03:39:55 +03:00
PHONY += help
2005-04-17 02:20:36 +04: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'
@echo ''
2006-01-25 09:13:18 +03:00
2018-11-29 06:56:30 +03:00
PHONY += prepare
2005-04-17 02:20:36 +04:00
e n d i f # KBUILD_EXTMOD
2019-08-10 18:53:04 +03:00
# Handle descending into subdirectories listed in $(build-dirs)
# 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
PHONY += descend $( build-dirs)
descend : $( build -dirs )
$(build-dirs) : prepare
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 18:19:18 +03:00
$( Q) $( MAKE) $( build) = $@ single-build= $( single-build) need-builtin= 1 need-modorder= 1
2019-08-10 18:53:04 +03:00
2019-08-10 18:53:05 +03:00
clean-dirs := $( addprefix _clean_, $( clean-dirs) )
PHONY += $( clean-dirs) clean
$(clean-dirs) :
$( Q) $( MAKE) $( clean) = $( patsubst _clean_%,%,$@ )
2010-09-06 14:00:08 +04:00
clean : $( clean -dirs )
$( call cmd,rmdirs)
$( call cmd,rmfiles)
2011-05-11 02:47:16 +04:00
@find $( if $( KBUILD_EXTMOD) , $( KBUILD_EXTMOD) , .) $( RCS_FIND_IGNORE) \
2017-11-16 19:49:13 +03:00
\( -name '*.[aios]' -o -name '*.ko' -o -name '.*.cmd' \
2018-09-06 21:26:07 +03:00
-o -name '*.ko.*' \
-o -name '*.dtb' -o -name '*.dtb.S' -o -name '*.dt.yaml' \
2017-11-16 19:49:13 +03:00
-o -name '*.dwo' -o -name '*.lst' \
2019-09-06 13:32:31 +03:00
-o -name '*.su' -o -name '*.mod' -o -name '*.ns_deps' \
2010-09-06 14:00:08 +04:00
-o -name '.*.d' -o -name '.*.tmp' -o -name '*.mod.c' \
2018-03-23 16:04:31 +03:00
-o -name '*.lex.c' -o -name '*.tab.[ch]' \
2018-03-23 16:04:37 +03:00
-o -name '*.asn1.[ch]' \
2010-09-06 14:00:08 +04:00
-o -name '*.symtypes' -o -name 'modules.order' \
-o -name modules.builtin -o -name '.tmp_*.o.*' \
2016-05-24 01:09:38 +03:00
-o -name '*.c.[012]*.*' \
2017-04-24 23:04:58 +03:00
-o -name '*.ll' \
2010-09-06 14:00:08 +04:00
-o -name '*.gcno' \) -type f -print | xargs rm -f
2005-04-17 02:20:36 +04:00
# Generate tags for editors
# ---------------------------------------------------------------------------
2008-12-04 00:24:13 +03:00
quiet_cmd_tags = GEN $@
2019-08-25 16:28:37 +03:00
cmd_tags = $( BASH) $( srctree) /scripts/tags.sh $@
2005-04-17 02:20:36 +04:00
2011-01-14 15:07:05 +03:00
tags TAGS cscope gtags : FORCE
2005-04-17 02:20:36 +04:00
$( call cmd,tags)
2019-09-06 13:32:32 +03:00
# Script to generate missing namespace dependencies
# ---------------------------------------------------------------------------
PHONY += nsdeps
nsdeps : modules
$( Q) $( MAKE) -f $( srctree) /scripts/Makefile.modpost nsdeps
$( Q) $( CONFIG_SHELL) $( srctree) /scripts/$@
2005-04-17 02:20:36 +04:00
# Scripts to check various things for consistency
# ---------------------------------------------------------------------------
2011-04-27 01:15:01 +04:00
PHONY += includecheck versioncheck coccicheck namespacecheck export_report
2005-04-17 02:20:36 +04:00
includecheck :
2011-04-27 01:18:29 +04:00
find $( srctree) /* $( RCS_FIND_IGNORE) \
2005-04-17 02:20:36 +04:00
-name '*.[hcS]' -type f -print | sort \
2007-11-05 13:51:44 +03:00
| xargs $( PERL) -w $( srctree) /scripts/checkincludes.pl
2005-04-17 02:20:36 +04:00
versioncheck :
2011-04-27 01:19:28 +04:00
find $( srctree) /* $( RCS_FIND_IGNORE) \
2005-04-17 02:20:36 +04:00
-name '*.[hcS]' -type f -print | sort \
2007-11-05 13:51:44 +03:00
| xargs $( PERL) -w $( srctree) /scripts/checkversion.pl
2005-04-17 02:20:36 +04:00
2010-06-06 19:15:01 +04:00
coccicheck :
2019-08-25 16:28:37 +03:00
$( Q) $( BASH) $( srctree) /scripts/$@
2010-06-06 19:15:01 +04:00
2005-04-17 02:20:36 +04:00
namespacecheck :
$( PERL) $( srctree) /scripts/namespace.pl
2007-08-25 01:04:56 +04:00
export_report :
$( PERL) $( srctree) /scripts/export_report.pl
2013-06-24 16:48:37 +04:00
PHONY += checkstack kernelrelease kernelversion image_name
2006-09-27 12:50:37 +04:00
2006-12-13 11:34:12 +03: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.
i f e q ( $( ARCH ) , u m )
CHECKSTACK_ARCH := $( SUBARCH)
e l s e
CHECKSTACK_ARCH := $( ARCH)
e n d i f
2005-04-17 02:20:36 +04:00
checkstack :
$( OBJDUMP) -d vmlinux $$ ( find . -name '*.ko' ) | \
2019-07-06 06:07:11 +03:00
$( PERL) $( srctree) /scripts/checkstack.pl $( CHECKSTACK_ARCH)
2005-04-17 02:20:36 +04:00
2010-08-20 13:36:06 +04:00
kernelrelease :
@echo " $( KERNELVERSION) $$ ( $( CONFIG_SHELL) $( srctree) /scripts/setlocalversion $( srctree) ) "
2010-06-28 06:45:21 +04:00
2006-01-09 23:20:34 +03:00
kernelversion :
2006-01-16 14:12:12 +03:00
@echo $( KERNELVERSION)
2005-04-17 02:20:36 +04:00
2013-06-24 16:48:37 +04:00
image_name :
@echo $( KBUILD_IMAGE)
2012-04-11 20:36:18 +04:00
# Clear a bunch of variables before executing the submake
2019-02-22 10:40:06 +03:00
i f e q ( $( quiet ) , s i l e n t _ )
tools_silent = s
e n d i f
2012-04-11 20:36:18 +04:00
tools/ : FORCE
2012-11-06 01:02:08 +04:00
$( Q) mkdir -p $( objtree) /tools
2019-07-06 06:07:11 +03:00
$( Q) $( MAKE) LDFLAGS = MAKEFLAGS = " $( tools_silent) $( filter --j% -j,$( MAKEFLAGS) ) " O = $( abspath $( objtree) ) subdir = tools -C $( srctree) /tools/
2012-04-11 20:36:18 +04:00
tools/% : FORCE
2012-11-06 01:02:08 +04:00
$( Q) mkdir -p $( objtree) /tools
2019-07-06 06:07:11 +03:00
$( Q) $( MAKE) LDFLAGS = MAKEFLAGS = " $( tools_silent) $( filter --j% -j,$( MAKEFLAGS) ) " O = $( abspath $( objtree) ) subdir = tools -C $( srctree) /tools/ $*
2012-04-11 20:36:18 +04:00
2006-01-25 09:13:18 +03:00
# Single targets
# ---------------------------------------------------------------------------
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 18:19:18 +03:00
# To build individual files in subdirectories, you can do like this:
#
# make foo/bar/baz.s
2006-04-05 14:57:21 +04: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 18:19:18 +03:00
# 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/
i f d e f s i n g l e - b u i l d
# .ko is special because modpost is needed
2019-10-16 08:12:15 +03:00
single-ko := $( sort $( filter %.ko, $( MAKECMDGOALS) ) )
single-no-ko := $( sort $( patsubst %.ko,%.mod, $( MAKECMDGOALS) ) )
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 18:19:18 +03:00
$(single-ko) : single_modpost
@:
$(single-no-ko) : descend
@:
2019-08-02 13:23:58 +03:00
i f e q ( $( KBUILD_EXTMOD ) , )
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 18:19:18 +03:00
# For the single build of in-tree modules, use a temporary file to avoid
2019-08-02 13:23:58 +03:00
# the situation of modules_install installing an invalid modules.order.
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 18:19:18 +03:00
MODORDER := .modules.tmp
2019-08-02 13:23:58 +03:00
e n d i f
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 18:19:18 +03:00
PHONY += single_modpost
single_modpost : $( single -no -ko )
$( Q) { $( foreach m, $( single-ko) , echo $( extmod-prefix) $m ; ) } > $( MODORDER)
2019-08-02 13:23:58 +03:00
$( Q) $( MAKE) -f $( srctree) /scripts/Makefile.modpost
2006-01-25 09:13:18 +03: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 18:19:18 +03:00
KBUILD_MODULES := 1
2019-02-14 06:05:17 +03: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 18:19:18 +03:00
export KBUILD_SINGLE_TARGETS := $( addprefix $( extmod-prefix) , $( single-no-ko) )
single-build = $( if $( filter-out $@ /, $( single-no-ko) ) ,1)
e n d i f
2006-01-25 09:13:18 +03:00
2014-04-28 11:26:18 +04:00
# FIXME Should go into a make.lib or something
2005-04-17 02:20:36 +04:00
# ===========================================================================
quiet_cmd_rmdirs = $( if $( wildcard $( rm-dirs) ) ,CLEAN $( wildcard $( rm-dirs) ) )
cmd_rmdirs = rm -rf $( rm-dirs)
quiet_cmd_rmfiles = $( if $( wildcard $( rm-files) ) ,CLEAN $( wildcard $( rm-files) ) )
cmd_rmfiles = rm -f $( rm-files)
2008-04-22 02:53:56 +04:00
# Run depmod only if we have System.map and depmod is executable
2007-10-18 23:24:21 +04:00
quiet_cmd_depmod = DEPMOD $( KERNELRELEASE)
2011-06-16 00:15:47 +04:00
cmd_depmod = $( CONFIG_SHELL) $( srctree) /scripts/depmod.sh $( DEPMOD) \
2018-05-09 10:23:48 +03:00
$( KERNELRELEASE)
2007-10-18 23:24:21 +04: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 04:05:22 +03:00
# read saved command lines for existing targets
existing-targets := $( wildcard $( sort $( targets) ) )
2005-04-17 02:20:36 +04:00
2019-02-22 10:40:08 +03:00
- i n c l u d e $( foreach f ,$ ( existing -targets ) ,$ ( dir $ ( f ) ) .$ ( notdir $ ( f ) ) .cmd )
2005-04-17 02:20:36 +04:00
2019-08-10 18:53:03 +03:00
e n d i f # config-targets
e n d i f # mixed-build
e n d i f # need-sub-make
2005-04-17 02:20:36 +04:00
2006-03-06 01:14:10 +03:00
PHONY += FORCE
2005-04-17 02:20:36 +04:00
FORCE :
2006-03-06 01:14:10 +03:00
2018-07-05 06:33:07 +03:00
# Declare the contents of the PHONY variable as phony. We keep that
2009-04-09 15:34:34 +04:00
# information in a variable so we can use it in if_changed and friends.
2006-03-06 01:14:10 +03:00
.PHONY : $( PHONY )