13 Jan, 2021
2 commits
-
Modules with a large number of compilation units may be
exceeding AR and LD command argument list. Handle this gracefully by
writing the long argument list in a file. The command line options
read from file are inserted in place of the original @file option.The usage is well documented at
https://www.gnu.org/software/make/manual/html_node/File-Function.htmlBug: 175420573
Change-Id: I3f9b8b9c59b9ba0c01ddd00d39fc3bbc62fda832
Signed-off-by: Mahesh Kumar Kalikot Veetil
Signed-off-by: Jeff Johnson -
Modules with a large number of compilation units can exceed execv
argument list resulting in E2BIG (Argument list too long) error.Fix this by replacing shell 'echo > file' into a more native
$(file op filename[,text]) option.Bug: 175420575
Change-Id: I9bc495482f16f2c9b4e05a4cb5b2283ff0c0439d
Signed-off-by: Mahesh Kumar Kalikot Veetil
Signed-off-by: Jeff Johnson
17 Dec, 2020
5 commits
-
With LTO, LLVM bitcode won't be compiled into native code until
modpost_link, or modfinal for modules. This change postpones calls
to objtool until after these steps, and moves objtool_args to
Makefile.lib, so the arguments can be reused in Makefile.modfinal.As we didn't have objects to process earlier, we use --duplicate
when processing vmlinux.o. This change also disables unreachable
instruction warnings with LTO to avoid warnings about the int3
padding between functions.Bug: 145210207
Change-Id: I72615f7062d218bf612a5d929f2efb75a18538dd
Link: https://lore.kernel.org/lkml/20201013003203.4168817-12-samitolvanen@google.com/
Signed-off-by: Sami Tolvanen
Reviewed-by: Kees Cook -
This change adds build support for using objtool to generate
__mcount_loc sections.Bug: 145210207
Change-Id: I58f4eae487a1f2cc1486daa6ae4927a2ef5f7137
Link: https://lore.kernel.org/lkml/20201013003203.4168817-6-samitolvanen@google.com/
Signed-off-by: Sami Tolvanen -
With CONFIG_MODVERSIONS, version information is linked into each
compilation unit that exports symbols. With LTO, we cannot use this
method as all C code is compiled into LLVM bitcode instead. This
change collects symbol versions into .symversions files and merges
them in link-vmlinux.sh where they are all linked into vmlinux.o at
the same time.Bug: 145210207
Change-Id: Icd8fd0c760891eff7a0ed12ce48b4db2a85fc2ad
Link: https://lore.kernel.org/lkml/20201211184633.3213045-1-samitolvanen@google.com/
Signed-off-by: Sami Tolvanen
Reviewed-by: Kees Cook -
This change adds build system support for Clang's Link Time
Optimization (LTO). With -flto, instead of ELF object files, Clang
produces LLVM bitcode, which is compiled into native code at link
time, allowing the final binary to be optimized globally. For more
details, see:https://llvm.org/docs/LinkTimeOptimization.html
The Kconfig option CONFIG_LTO_CLANG is implemented as a choice,
which defaults to LTO being disabled. To use LTO, the architecture
must select ARCH_SUPPORTS_LTO_CLANG and support:- compiling with Clang,
- compiling all assembly code with Clang's integrated assembler,
- and linking with LLD.While using CONFIG_LTO_CLANG_FULL results in the best runtime
performance, the compilation is not scalable in time or
memory. CONFIG_LTO_CLANG_THIN enables ThinLTO, which allows
parallel optimization and faster incremental builds. ThinLTO is
used by default if the architecture also selects
ARCH_SUPPORTS_LTO_CLANG_THIN:https://clang.llvm.org/docs/ThinLTO.html
To enable LTO, LLVM tools must be used to handle bitcode files, by
passing LLVM=1 and LLVM_IAS=1 options to make:$ make LLVM=1 LLVM_IAS=1 defconfig
$ scripts/config -e LTO_CLANG_THIN
$ make LLVM=1 LLVM_IAS=1To prepare for LTO support with other compilers, common parts are
gated behind the CONFIG_LTO option, and LTO can be disabled for
specific files by filtering out CC_FLAGS_LTO.Bug: 145210207
Change-Id: I85eb4523ea787e4f9884e12ed6301f876d0d888e
Link: https://lore.kernel.org/lkml/20201211184633.3213045-1-samitolvanen@google.com/
Signed-off-by: Sami Tolvanen
Reviewed-by: Kees Cook -
Move function tracer options to Kconfig to make it easier to add
new methods for generating __mcount_loc, and to make the options
available also when building kernel modules.Note that FTRACE_MCOUNT_USE_* options are updated on rebuild and
therefore, work even if the .config was generated in a different
environment.Bug: 145210207
Change-Id: I6fc38abde50b602788148cb236aba1261affa896
Link: https://lore.kernel.org/lkml/20201211184633.3213045-1-samitolvanen@google.com/
Signed-off-by: Sami Tolvanen
Acked-by: Steven Rostedt (VMware)
06 Dec, 2020
1 commit
-
"xargs echo" is not a safe way to remove line breaks because the input
may exceed the command line limit and xargs may break it up into
multiple invocations of echo. This should never happen because
scripts/gen_autoksyms.sh expects all undefined symbols are placed in
the second line of .mod files.One possible way is to replace "xargs echo" with
"sed ':x;N;$!bx;s/\n/ /g'" or something, but I rewrote the code by
using awk because it is more readable.This issue was reported by Sami Tolvanen; in his Clang LTO patch set,
$(multi-used-m) is no longer an ELF object, but a thin archive that
contains LLVM bitcode files. llvm-nm prints out symbols for each
archive member separately, which results a lot of dupications, in some
places, beyond the system-defined limit.This problem must be fixed irrespective of LTO, and we must ensure
zero possibility of having this issue.Link: https://lkml.org/lkml/2020/12/1/1658
Reported-by: Sami Tolvanen
Signed-off-by: Masahiro Yamada
Reviewed-by: Sami Tolvanen
20 Oct, 2020
1 commit
-
This change removes all instances of DISABLE_LTO from
Makefiles, as they are currently unused, and the preferred
method of disabling LTO is to filter out the flags instead.Note added by Masahiro Yamada:
DISABLE_LTO was added as preparation for GCC LTO, but GCC LTO was
not pulled into the mainline. (https://lkml.org/lkml/2014/4/8/272)Suggested-by: Kees Cook
Signed-off-by: Sami Tolvanen
Reviewed-by: Kees Cook
Signed-off-by: Masahiro Yamada
10 Aug, 2020
3 commits
-
The conditional:
ifneq ($(hostprogs),)
... is evaluated to true if $(hostprogs) does not contain any word but
whitespace characters.ifneq ($(strip $(hostprogs)),)
... is a safe way to avoid interpreting whitespace as a non-empty value,
but I'd rather want to use the side-effect of $(sort ...) to do the
equivalent.$(sort ...) is used in scripts/Makefile.host in order to drop duplication
in $(hostprogs). It is also useful to strip excessive spaces.Move $(sort ...) before evaluating the ifneq.
Signed-off-by: Masahiro Yamada
-
The host shared library rules are currently implemented in
scripts/Makefile.host, but actually GCC-plugin is the only user of
them. (The VDSO .so files are built for the target by different
build rules) Hence, they do not need to be treewide available.Move all the relevant build rules to scripts/gcc-plugins/Makefile.
I also optimized the build steps so *.so is directly built from .c
because every upstream plugin is compiled from a single source file.I am still keeping the multi-file plugin support, which Kees Cook
mentioned might be needed by out-of-tree plugins.
(https://lkml.org/lkml/2019/1/11/1107)If the plugin, foo.so, is compiled from two files foo.c and foo2.c,
then you can do like follows:foo-objs := foo.o foo2.o
Single-file plugins do not need the *-objs notation.
Signed-off-by: Masahiro Yamada
Acked-by: Kees Cook -
Currently, the directories of objects are automatically created
only for O= builds.It should not hurt to cater to this for in-tree builds too.
Signed-off-by: Masahiro Yamada
07 Jul, 2020
1 commit
-
Since the pre-git time the checker is run first, before the compiler.
But if the source file contains some syntax error, the warnings from
the compiler are more useful than those from sparse (and other
checker most probably too).So move the 'check' command to run after the compiler.
Signed-off-by: Luc Van Oostenryck
Signed-off-by: Masahiro Yamada
03 Jun, 2020
1 commit
-
Make modules.order depend on $(obj-m), and use if_changed to build it.
This will avoid unneeded update of modules.order, which will be useful
to optimize the modpost stage.Currently, the second pass of modpost is always invoked. By checking the
timestamp of modules.order, we can avoid the unneeded modpost.Signed-off-by: Masahiro Yamada
01 Jun, 2020
1 commit
-
Remove lib-target, builtin-target, modorder-target, and modtargets.
Instead, add targets-for-builtin and targets-for-modules.
Signed-off-by: Masahiro Yamada
25 May, 2020
5 commits
-
built-in.a contains the built-in object paths from the current and sub
directories.module.order collects the module paths from the current and sub
directories.Make their build rules look more symmetrical.
Signed-off-by: Masahiro Yamada
-
I think subdir-builtin is clearer.
While I was here, I made its build rule explicit.
Signed-off-by: Masahiro Yamada
-
Save $(addprefix ...) for subdir-obj-y.
Signed-off-by: Masahiro Yamada
-
Do not try to build any module-related artifacts when CONFIG_MODULES
is disabled.Signed-off-by: Masahiro Yamada
-
I do not see a good reason to add ifdef here.
Signed-off-by: Masahiro Yamada
17 May, 2020
1 commit
-
Kbuild supports the infrastructure to build host programs, but there
was no support to build userspace programs for the target architecture
(i.e. the same architecture as the kernel).Sam Ravnborg worked on this in 2014 (https://lkml.org/lkml/2014/7/13/154),
but it was not merged. One problem at that time was, there was no good way
to know whether $(CC) can link standalone programs. In fact, pre-built
kernel.org toolchains [1] are often used for building the kernel, but they
do not provide libc.Now, we can handle this cleanly because the compiler capability is
evaluated at the Kconfig time. If $(CC) cannot link standalone programs,
the relevant options are hidden by 'depends on CC_CAN_LINK'.The implementation just mimics scripts/Makefile.host
The userspace programs are compiled with the same flags as the host
programs. In addition, it uses -m32 or -m64 if it is found in
$(KBUILD_CFLAGS).This new syntax has two usecases.
- Sample programs
Several userspace programs under samples/ include UAPI headers
installed in usr/include. Most of them were previously built for
the host architecture just to use the 'hostprogs' syntax.However, 'make headers' always works for the target architecture.
This caused the arch mismatch in cross-compiling. To fix this
distortion, sample code should be built for the target architecture.- Bpfilter
net/bpfilter/Makefile compiles bpfilter_umh as the user mode helper,
and embeds it into the kernel. Currently, it overrides HOSTCC with
CC to use the 'hostprogs' syntax. This hack should go away.[1]: https://mirrors.edge.kernel.org/pub/tools/crosstool/
Signed-off-by: Masahiro Yamada
Acked-by: Sam Ravnborg
08 Apr, 2020
2 commits
-
Kbuild supports not only obj-y but also lib-y to list objects linked to
vmlinux.The difference between them is that all the objects from obj-y are
forcibly linked to vmlinux, whereas the objects from lib-y are linked
as needed; if there is no user of a lib-y object, it is not linked.lib-y is intended to list utility functions that may be called from all
over the place (and may be unused at all), but it is a problem for
EXPORT_SYMBOL(). Even if there is no call-site in the vmlinux, we need
to keep exported symbols for the use from loadable modules.Commit 7f2084fa55e6 ("[kbuild] handle exports in lib-y objects reliably")
worked around it by linking a dummy object, lib-ksyms.o, which contains
references to all the symbols exported from lib.a in that directory.
It uses the linker script command, EXTERN. Unfortunately, the meaning of
EXTERN of ld.lld is different from that of ld.bfd. Therefore, this does
not work with LD=ld.lld (CBL issue #515).Anyway, the build rule of lib-ksyms.o is somewhat tricky. So, I want to
get rid of it.At first, I was thinking of accumulating lib-y objects into obj-y
(or even replacing lib-y with obj-y entirely), but the lib-y syntax
is used beyond the ordinary use in lib/ and arch/*/lib/.Examples:
- drivers/firmware/efi/libstub/Makefile builds lib.a, which is linked
into vmlinux in the own way (arm64), or linked to the decompressor
(arm, x86).- arch/alpha/lib/Makefile builds lib.a which is linked not only to
vmlinux, but also to bootloaders in arch/alpha/boot/Makefile.- arch/xtensa/boot/lib/Makefile builds lib.a for use from
arch/xtensa/boot/boot-redboot/Makefile.One more thing, adding everything to obj-y would increase the vmlinux
size of allnoconfig (or tinyconfig).For less impact, I tweaked the destination of lib.a at the top Makefile;
when CONFIG_MODULES=y, lib.a goes to KBUILD_VMLINUX_OBJS, which is
forcibly linked to vmlinux, otherwise lib.a goes to KBUILD_VMLINUX_LIBS
as before.The size impact for normal usecases is quite small since at lease one
symbol in every lib-y object is eventually called by someone. In case
you are intrested, here are the figures.x86_64_defconfig:
text data bss dec hex filename
19566602 5422072 1589328 26578002 1958c52 vmlinux.before
19566932 5422104 1589328 26578364 1958dbc vmlinux.afterThe case with the biggest impact is allnoconfig + CONFIG_MODULES=y.
ARCH=x86 allnoconfig + CONFIG_MODULES=y:
text data bss dec hex filename
1175162 254740 1220608 2650510 28718e vmlinux.before
1177974 254836 1220608 2653418 287cea vmlinux.afterHopefully this is still not a big deal. The per-file trimming with the
static library is not so effective after all.If fine-grained optimization is desired, some architectures support
CONFIG_LD_DEAD_CODE_DATA_ELIMINATION, which trims dead code per-symbol
basis. When LTO is supported in mainline, even better optimization will
be possible.Link: https://github.com/ClangBuiltLinux/linux/issues/515
Signed-off-by: Masahiro Yamada
Reported-by: kbuild test robot
Reviewed-by: Nick Desaulniers -
Nobody was opposed to raising minimum GCC version to 4.8 [1]
So, we will drop GCC = 4.8.This commit drops the plugin support for GCC
Acked-by: Kees Cook
04 Feb, 2020
1 commit
-
In old days, the "host-progs" syntax was used for specifying host
programs. It was renamed to the current "hostprogs-y" in 2004.It is typically useful in scripts/Makefile because it allows Kbuild to
selectively compile host programs based on the kernel configuration.This commit renames like follows:
always -> always-y
hostprogs-y -> hostprogsSo, scripts/Makefile will look like this:
always-$(CONFIG_BUILD_BIN2C) += ...
always-$(CONFIG_KALLSYMS) += ...
...
hostprogs := $(always-y) $(always-m)I think this makes more sense because a host program is always a host
program, irrespective of the kernel configuration. We want to specify
which ones to compile by CONFIG options, so always-y will be handier.The "always", "hostprogs-y", "hostprogs-m" will be kept for backward
compatibility for a while.Signed-off-by: Masahiro Yamada
07 Jan, 2020
2 commits
-
The built-in.a in a sub-directory is created by descending into that
directory. It does not depend on the other sub-directories. Loosen
the dependency.Signed-off-by: Masahiro Yamada
-
Both 'obj-y += foo/' and 'obj-m += foo/' request Kbuild to visit the
sub-directory foo/, but the difference is that only the former combines
foo/built-in.a into the built-in.a of the current directory because
everything in sub-directories visited by obj-m is supposed to be modular.So, it makes sense to create built-in.a only if that sub-directory is
reachable by the chain of obj-y. Otherwise, built-in.a will not be
linked into vmlinux anyway. For the same reason, it is pointless to
compile obj-y objects in the directory visited by obj-m.Signed-off-by: Masahiro Yamada
14 Nov, 2019
1 commit
-
There are both positive and negative options about this feature.
At first, I thought it was a good idea, but actually Linus stated a
negative opinion (https://lkml.org/lkml/2019/9/29/227). I admit it
is ugly and annoying.The baseline I'd like to keep is the compile-test of uapi headers.
(Otherwise, kernel developers have no way to ensure the correctness
of the exported headers.)I will maintain a small build rule in usr/include/Makefile.
Remove the other header test functionality.Signed-off-by: Masahiro Yamada
11 Nov, 2019
2 commits
-
Since commit 394053f4a4b3 ("kbuild: make single targets work more
correctly"), building single targets is really slow.Speed it up by not descending into unrelated directories.
Signed-off-by: Masahiro Yamada
-
KBUILD_SINGLE_TARGETS does not need to contain all the targets.
Change it to keep track the targets only from the current directory
and its subdirectories.Signed-off-by: Masahiro Yamada
01 Oct, 2019
1 commit
-
Commit 40df759e2b9e ("kbuild: Fix build with binutils
Reviewed-by: Nick Desaulniers
Tested-by: Nick Desaulniers
06 Sep, 2019
1 commit
-
KBUILD_ENABLE_EXTRA_GCC_CHECKS started as a switch to add extra warning
options for GCC, but now it is a historical misnomer since we use it
also for Clang, DTC, and even kernel-doc.Rename it to more sensible, shorter KBUILD_EXTRA_WARN.
For the backward compatibility, KBUILD_ENABLE_EXTRA_GCC_CHECKS is still
supported (but not advertised in the documentation).I also fixed up 'make help', and updated the documentation.
Signed-off-by: Masahiro Yamada
Reviewed-by: Nathan Chancellor
Reviewed-by: Nick Desaulniers
Reviewed-by: Sedat Dilek
22 Aug, 2019
2 commits
-
Makefile.lib is included by Makefile.modfinal as well as Makefile.build.
Move modkern_cflags to Makefile.lib in order to simplify cmd_cc_o_c
in Makefile.modfinal. Move modkern_cflags as well for consistency.Signed-off-by: Masahiro Yamada
-
Add CONFIG_ASM_MODVERSIONS. This allows to remove one if-conditional
nesting in scripts/Makefile.build.scripts/Makefile.build is run every time Kbuild descends into a
sub-directory. So, I want to avoid $(wildcard ...) evaluation
where possible although computing $(wildcard ...) is so cheap that
it may not make measurable performance difference.Signed-off-by: Masahiro Yamada
Acked-by: Geert Uytterhoeven
21 Aug, 2019
1 commit
-
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.oThis 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
15 Aug, 2019
2 commits
-
For the single target building %.symtypes from %.S, $(a_flags) is
expanded into the _KERNEL flags even if the object is a part of a
module.$(real-obj-m:.o=.symtypes): modkern_aflags := $(KBUILD_AFLAGS_MODULE) $(AFLAGS_MODULE)
... would fix the issue, but it is not nice to duplicate similar code
for every suffix.Implement modkern_aflags in the same way as modkern_cflags.
Signed-off-by: Masahiro Yamada
-
Make it even shorter.
Signed-off-by: Masahiro Yamada
14 Aug, 2019
1 commit
-
$(basename ...) trims the last suffix. Using it is more intuitive in
my opinion.This pattern rule makes %.asn1.c and %.asn1.h at the same time.
Previously, the short log showed only either of them, depending on
the target file in question.To clarify that two files are being generated by the single recipe,
I changed the log as follows:Before:
ASN.1 crypto/asymmetric_keys/x509.asn1.c
After:
ASN.1 crypto/asymmetric_keys/x509.asn1.[ch]
Signed-off-by: Masahiro Yamada
10 Aug, 2019
3 commits
-
Since commit ff9b45c55b26 ("kbuild: modpost: read modules.order instead
of $(MODVERDIR)/*.mod"), a module is no longer built in the following
pattern:[Makefile]
subdir-y := some-module[some-module/Makefile]
obj-m := some-module.oYou cannot write Makefile this way in upstream because modules.order is
not correctly generated. subdir-y is used to descend to a sub-directory
that builds tools, device trees, etc.For external modules, the modules order does not matter. So, the
Makefile above was known to work.I believe the Makefile should be re-written as follows:
[Makefile]
obj-m := some-module/[some-module/Makefile]
obj-m := some-module.oHowever, people will have no idea if their Makefile suddenly stops
working. In fact, I received questions from multiple people.Show a warning for a while if obj-m is specified in a Makefile visited
by subdir-y or subdir-m.I touched the %/ rule to avoid false-positive warnings for the single
target.Cc: Jan Kiszka
Cc: Tom Stonecypher
Signed-off-by: Masahiro Yamada
Tested-by: Jan Kiszka -
The modules.order files in directories visited by the chain of obj-y
or obj-m are merged to the upper-level ones, and become parts of the
top-level modules.order. On the other hand, there is no need to
generate modules.order in directories visited by subdir-y or subdir-m
since they would become orphan anyway.Signed-off-by: Masahiro Yamada
-
The current implementation of need-builtin is false-positive,
for example, in the following Makefile:obj-m := foo/
obj-y := foo/bar/..., where foo/built-in.a is not required.
Signed-off-by: Masahiro Yamada