user/sven/linux.git/scripts/Kbuild.include, branch v4.9.135

kbuild: add .DELETE_ON_ERROR special target

2018-09-26T06:36:31Z

[ Upstream commit 9c2af1c7377a8a6ef86e5cabf80978f3dbbb25c0 ] If Make gets a fatal signal while a shell is executing, it may delete the target file that the recipe was supposed to update. This is needed to make sure that it is remade from scratch when Make is next run; if Make is interrupted after the recipe has begun to write the target file, it results in an incomplete file whose time stamp is newer than that of the prerequisites files. Make automatically deletes the incomplete file on interrupt unless the target is marked .PRECIOUS. The situation is just the same as when the shell fails for some reasons. Usually when a recipe line fails, if it has changed the target file at all, the file is corrupted, or at least it is not completely updated. Yet the file’s time stamp says that it is now up to date, so the next time Make runs, it will not try to update that file. However, Make does not cater to delete the incomplete target file in this case. We need to add .DELETE_ON_ERROR somewhere in the Makefile to request it. scripts/Kbuild.include seems a suitable place to add it because it is included from almost all sub-makes. Please note .DELETE_ON_ERROR is not effective for phony targets. The external module building should never ever touch the kernel tree. The following recipe fails if include/generated/autoconf.h is missing. However, include/config/auto.conf is not deleted since it is a phony target. PHONY += include/config/auto.conf include/config/auto.conf: $(Q)test -e include/generated/autoconf.h -a -e $@ || ( \ 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 ; \ /bin/false) Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

Kbuild: fix # escaping in .cmd files for future Make

2018-07-11T14:26:45Z

commit 9564a8cf422d7b58f6e857e3546d346fa970191e upstream. I tried building using a freshly built Make (4.2.1-69-g8a731d1), but already the objtool build broke with orc_dump.c: In function ‘orc_dump’: orc_dump.c:106:2: error: ‘elf_getshnum’ is deprecated [-Werror=deprecated-declarations] if (elf_getshdrnum(elf, &nr_sections)) { Turns out that with that new Make, the backslash was not removed, so cpp didn't see a #include directive, grep found nothing, and -DLIBELF_USE_DEPRECATED was wrongly put in CFLAGS. Now, that new Make behaviour is documented in their NEWS file: * WARNING: Backward-incompatibility! Number signs (#) appearing inside a macro reference or function invocation no longer introduce comments and should not be escaped with backslashes: thus a call such as: foo := $(shell echo '#') is legal. Previously the number sign needed to be escaped, for example: foo := $(shell echo '\#') Now this latter will resolve to "\#". If you want to write makefiles portable to both versions, assign the number sign to a variable: C := \# foo := $(shell echo '$C') This was claimed to be fixed in 3.81, but wasn't, for some reason. To detect this change search for 'nocomment' in the .FEATURES variable. This also fixes up the two make-cmd instances to replace # with $(pound) rather than with \#. There might very well be other places that need similar fixup in preparation for whatever future Make release contains the above change, but at least this builds an x86_64 defconfig with the new make. Link: https://bugzilla.kernel.org/show_bug.cgi?id=197847 Cc: Randy Dunlap Signed-off-by: Rasmus Villemoes Signed-off-by: Masahiro Yamada Signed-off-by: Greg Kroah-Hartman

kbuild: no gcc-plugins during cc-option tests

2016-08-09T00:49:05Z

The gcc-plugins arguments should not be included when performing cc-option tests. Steps to reproduce: 1) make mrproper 2) make defconfig 3) enable GCC_PLUGINS, GCC_PLUGIN_CYC_COMPLEXITY 4) enable FUNCTION_TRACER (it will select other options as well) 5) make && make modules Build errors: MODPOST 18 modules ERROR: "__fentry__" [net/netfilter/xt_nat.ko] undefined! ERROR: "__fentry__" [net/netfilter/xt_mark.ko] undefined! ERROR: "__fentry__" [net/netfilter/xt_addrtype.ko] undefined! ERROR: "__fentry__" [net/netfilter/xt_LOG.ko] undefined! ERROR: "__fentry__" [net/netfilter/nf_nat_sip.ko] undefined! ERROR: "__fentry__" [net/netfilter/nf_nat_irc.ko] undefined! ERROR: "__fentry__" [net/netfilter/nf_nat_ftp.ko] undefined! ERROR: "__fentry__" [net/netfilter/nf_nat.ko] undefined! Reported-by: Laura Abbott Signed-off-by: Emese Revfy [kees: renamed variable, clarified commit message] Signed-off-by: Kees Cook

Kbuild: don't add obj tree in additional includes

2016-07-18T19:31:35Z

When building with separate object directories and driver specific Makefiles that add additional header include paths, Kbuild adjusts the gcc flags so that we include both the directory in the source tree and in the object tree. However, due to another bug I fixed earlier, this did not actually include the correct directory in the object tree, so we know that we only really need the source tree here. Also, including the object tree sometimes causes warnings about nonexisting directories when the include path only exists in the source. This changes the logic to only emit the -I argument for the srctree, not for objects. We still need both $(srctree)/$(src) and $(obj) though, so I'm adding them manually. Signed-off-by: Arnd Bergmann Signed-off-by: Michal Marek

Kbuild: don't add ../../ to include path

2016-07-18T19:31:35Z

When we build with O=objdir and objdir is directly below the source tree, $(srctree) becomes '..'. When a Makefile adds a CFLAGS option like -Ipath/to/headers and we are building with a separate object directory, Kbuild tries to add two -I options, one for the source tree and one for the object tree. An absolute path is treated as a special case, and don't add this one twice. This also normally catches -I$(srctree)/$(src) as $(srctree) usually is an absolute directory like /home/arnd/linux/. The combination of the two behaviors however results in an invalid path name to be included: we get both ../$(src) and ../../$(src), the latter one pointing outside of the source tree, usually to a nonexisting directory. Building with 'make W=1' makes this obvious: cc1: error: ../../arch/arm/mach-s3c24xx/include: No such file or directory [-Werror=missing-include-dirs] This adds another special case, treating path names starting with ../ like those starting with / so we don't try to prefix that with $(srctree). Signed-off-by: Arnd Bergmann Signed-off-by: Michal Marek

kbuild: fix if_change and friends to consider argument order

2016-05-10T19:21:14Z

Currently, arg-check is implemented as follows: arg-check = $(strip $(filter-out $(cmd_$(1)), $(cmd_$@)) \ $(filter-out $(cmd_$@), $(cmd_$(1))) ) This does not care about the order of arguments that appear in $(cmd_$(1)) and $(cmd_$@). So, if_changed and friends never rebuild the target if only the argument order is changed. This is a problem when the link order is changed. Apparently, obj-y += foo.o obj-y += bar.o and obj-y += bar.o obj-y += foo.o should be distinguished because the link order determines the probe order of drivers. So, built-in.o should be rebuilt when the order of objects is changed. This commit fixes arg-check to compare the old/current commands including the argument order. Of course, this change has a side effect; Kbuild will react to the change of compile option order. For example, "-DFOO -DBAR" and "-DBAR -DFOO" should give no difference to the build result, but false positive should be better than false negative. I am moving space_escape to the top of Kbuild.include just for a matter of preference. In practical terms, space_escape can be defined after arg-check because arg-check uses "=" flavor, not ":=". Having said that, collecting convenient variables in one place makes sense from the point of readability. Chaining "%%%SPACE%%%" to "_-_SPACE_-_" is also a matter of taste at this point. Actually, it can be arbitrary as long as it is an unlikely used string. The only problem I see in "%%%SPACE%%%" is that "%" is a special character in "$(patsubst ...)" context. This commit just uses "$(subst ...)" for arg-check, but I am fixing it now in case we might want to use it in $(patsubst ...) context in the future. Signed-off-by: Masahiro Yamada Signed-off-by: Michal Marek

kbuild: fix ksym_dep_filter when multiple EXPORT_SYMBOL() on the same line

2016-05-10T15:24:15Z

In kernel/cgroup.c there is: #define SUBSYS(_x) \ DEFINE_STATIC_KEY_TRUE(_x ## _cgrp_subsys_enabled_key); \ DEFINE_STATIC_KEY_TRUE(_x ## _cgrp_subsys_on_dfl_key); \ EXPORT_SYMBOL_GPL(_x ## _cgrp_subsys_enabled_key); \ EXPORT_SYMBOL_GPL(_x ## _cgrp_subsys_on_dfl_key); The expansion of this macro causes multiple EXPORT_SYMBOL_GPL() instances to appear on the same preprocessor line output, confusing the sed script expecting only one of them per line. Unfortunately this can't be fixed nicely in the sed script as sed's regexp can't do non greedy matching. Fix this by turning any semicolon into a line break before filtering. Reported-by: Arnd Bergmann Signed-off-by: Nicolas Pitre Signed-off-by: Michal Marek

kbuild: adjust ksym_dep_filter for some cmd_* renames

2016-04-27T08:36:38Z

The following renames occurred recently: cmd_cc_i_c --> cmd_cpp_i_c cmd_as_s_S --> cmd_cpp_s_S The respective cc_*_c and as_*_S patterns no longer match the above therefore additional patterns are needed. Signed-off-by: Nicolas Pitre Signed-off-by: Michal Marek

kbuild: add fine grained build dependencies for exported symbols

2016-03-29T20:30:56Z

Like with kconfig options, we now have the ability to compile in and out individual EXPORT_SYMBOL() declarations based on the content of include/generated/autoksyms.h. However we don't want the entire world to be rebuilt whenever that file is touched. Let's apply the same build dependency trick used for CONFIG_* symbols where the time stamp of empty files whose paths matching those symbols is used to trigger fine grained rebuilds. In our case the key is the symbol name passed to EXPORT_SYMBOL(). However, unlike config options, we cannot just use fixdep to parse the source code for EXPORT_SYMBOL(ksym) because several variants exist and parsing them all in a separate tool, and keeping it in synch, is not trivially maintainable. Furthermore, there are variants such as EXPORT_SYMBOL_GPL(pci_user_read_config_##size); that are instanciated via a macro for which we can't easily determine the actual exported symbol name(s) short of actually running the preprocessor on them. Storing the symbol name string in a special ELF section doesn't work for targets that output assembly or preprocessed source. So the best way is really to leverage the preprocessor by having it output actual symbol names anchored by a special sequence that can be easily filtered out. Then the list of symbols is simply fed to fixdep to be merged with the other dependencies. That implies the preprocessor is executed twice for each source file. A previous attempt relied on a warning pragma for each EXPORT_SYMBOL() instance that was filtered apart from stderr by the build system with a sed script during the actual compilation pass. Unfortunately the preprocessor/compiler diagnostic output isn't stable between versions and this solution, although more efficient, was deemed too fragile. Because of the lowercasing performed by fixdep, there might be name collisions triggering spurious rebuilds for similar symbols. But this shouldn't be a big issue in practice. (This is the case for CONFIG_* symbols and I didn't want to be different here, whatever the original reason for doing so.) To avoid needless build overhead, the exported symbol name gathering is performed only when CONFIG_TRIM_UNUSED_KSYMS is selected. Signed-off-by: Nicolas Pitre Acked-by: Rusty Russell

kbuild: de-duplicate fixdep usage

2016-03-29T20:30:56Z

The generation and postprocessing of automatic dependency rules is duplicated in rule_cc_o_c, rule_as_o_S and if_changed_dep. Since this is not a trivial one-liner action, it is now abstracted under cmd_and_fixdep to simplify things and make future changes in this area easier. In the rule_cc_o_c and rule_as_o_S cases that means the order of some commands has been altered, namely fixdep and related file manipulations are executed earlier, but they didn't depend on those commands that now execute later. Signed-off-by: Nicolas Pitre