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

kbuild: improve cc-option to clean up all temporary files

2020-06-30T19:38:43Z

[ Upstream commit f2f02ebd8f3833626642688b2d2c6a7b3c141fa9 ] When cc-option and friends evaluate compiler flags, the temporary file $$TMP is created as an output object, and automatically cleaned up. The actual file path of $$TMP is ..tmp, here is the process ID of $(shell ...) invoked from cc-option. (Please note $$$$ is the escape sequence of $$). Such garbage files are cleaned up in most cases, but some compiler flags create additional output files. For example, -gsplit-dwarf creates a .dwo file. When CONFIG_DEBUG_INFO_SPLIT=y, you will see a bunch of ..dwo files left in the top of build directories. You may not notice them unless you do 'ls -a', but the garbage files will increase every time you run 'make'. This commit changes the temporary object path to .tmp_/tmp, and removes .tmp_ directory when exiting. Separate build artifacts such as *.dwo will be cleaned up all together because their file paths are usually determined based on the base name of the object. Another example is -ftest-coverage, which outputs the coverage data into .gcno Signed-off-by: Masahiro Yamada Signed-off-by: Sasha Levin

kbuild: simplify ld-option implementation

2019-05-02T07:31:59Z

commit 0294e6f4a0006856e1f36b8cd8fa088d9e499e98 upstream. Currently, linker options are tested by the coordination of $(CC) and $(LD) because $(LD) needs some object to link. As commit 86a9df597cdd ("kbuild: fix linker feature test macros when cross compiling with Clang") addressed, we need to make sure $(CC) and $(LD) agree the underlying architecture of the passed object. This could be a bit complex when we combine tools from different groups. For example, we can use clang for $(CC), but we still need to rely on GCC toolchain for $(LD). So, I was searching for a way of standalone testing of linker options. A trick I found is to use '-v'; this not only prints the version string, but also tests if the given option is recognized. If a given option is supported, $ aarch64-linux-gnu-ld -v --fix-cortex-a53-843419 GNU ld (Linaro_Binutils-2017.11) 2.28.2.20170706 $ echo $? 0 If unsupported, $ aarch64-linux-gnu-ld -v --fix-cortex-a53-843419 GNU ld (crosstool-NG linaro-1.13.1-4.7-2013.04-20130415 - Linaro GCC 2013.04) 2.23.1 aarch64-linux-gnu-ld: unrecognized option '--fix-cortex-a53-843419' aarch64-linux-gnu-ld: use the --help option for usage information $ echo $? 1 Gold works likewise. $ aarch64-linux-gnu-ld.gold -v --fix-cortex-a53-843419 GNU gold (Linaro_Binutils-2017.11 2.28.2.20170706) 1.14 masahiro@pug:~/ref/linux$ echo $? 0 $ aarch64-linux-gnu-ld.gold -v --fix-cortex-a53-999999 GNU gold (Linaro_Binutils-2017.11 2.28.2.20170706) 1.14 aarch64-linux-gnu-ld.gold: --fix-cortex-a53-999999: unknown option aarch64-linux-gnu-ld.gold: use the --help option for usage information $ echo $? 1 LLD too. $ ld.lld -v --gc-sections LLD 7.0.0 (http://llvm.org/git/lld.git 4a0e4190e74cea19f8a8dc625ccaebdf8b5d1585) (compatible with GNU linkers) $ echo $? 0 $ ld.lld -v --fix-cortex-a53-843419 LLD 7.0.0 (http://llvm.org/git/lld.git 4a0e4190e74cea19f8a8dc625ccaebdf8b5d1585) (compatible with GNU linkers) $ echo $? 0 $ ld.lld -v --fix-cortex-a53-999999 ld.lld: error: unknown argument: --fix-cortex-a53-999999 LLD 7.0.0 (http://llvm.org/git/lld.git 4a0e4190e74cea19f8a8dc625ccaebdf8b5d1585) (compatible with GNU linkers) $ echo $? 1 Signed-off-by: Masahiro Yamada Tested-by: Nick Desaulniers [nc: try-run-cached was added later, just use try-run, which is the current mainline state] Signed-off-by: Nathan Chancellor Signed-off-by: Greg Kroah-Hartman

kbuild: fix linker feature test macros when cross compiling with Clang

2018-12-13T08:20:30Z

(commit 86a9df597cdd564d2d29c65897bcad42519e3678 upstream) I was not seeing my linker flags getting added when using ld-option when cross compiling with Clang. Upon investigation, this seems to be due to a difference in how GCC vs Clang handle cross compilation. GCC is configured at build time to support one backend, that is implicit when compiling. Clang is explicit via the use of `-target ` and ships with all supported backends by default. GNU Make feature test macros that compile then link will always fail when cross compiling with Clang unless Clang's triple is passed along to the compiler. For example: $ clang -x c /dev/null -c -o temp.o $ aarch64-linux-android/bin/ld -E temp.o aarch64-linux-android/bin/ld: unknown architecture of input file `temp.o' is incompatible with aarch64 output aarch64-linux-android/bin/ld: warning: cannot find entry symbol _start; defaulting to 0000000000400078 $ echo $? 1 $ clang -target aarch64-linux-android- -x c /dev/null -c -o temp.o $ aarch64-linux-android/bin/ld -E temp.o aarch64-linux-android/bin/ld: warning: cannot find entry symbol _start; defaulting to 00000000004002e4 $ echo $? 0 This causes conditional checks that invoke $(CC) without the target triple, then $(LD) on the result, to always fail. Suggested-by: Masahiro Yamada Signed-off-by: Nick Desaulniers Reviewed-by: Matthias Kaehlcke Signed-off-by: Masahiro Yamada [ND: readjusted for context] Signed-off-by: Greg Kroah-Hartman

kbuild: Add __cc-option macro

2018-11-23T07:20:35Z

commit 9f3f1fd299768782465cb32cdf0dd4528d11f26b upstream. cc-option uses KBUILD_CFLAGS and KBUILD_CPPFLAGS when it determines whether an option is supported or not. This is fine for options used to build the kernel itself, however some components like the x86 boot code use a different set of flags. Add the new macro __cc-option which is a more generic version of cc-option with additional parameters. One parameter is the compiler with which the check should be performed, the other the compiler options to be used instead KBUILD_C*FLAGS. Refactor cc-option and hostcc-option to use __cc-option and move hostcc-option to scripts/Kbuild.include. Suggested-by: Arnd Bergmann Suggested-by: Masahiro Yamada Signed-off-by: Matthias Kaehlcke Acked-by: Arnd Bergmann Acked-by: Michal Marek Signed-off-by: Masahiro Yamada Signed-off-by: Nick Desaulniers Signed-off-by: Greg Kroah-Hartman

kbuild, LLVMLinux: Add -Werror to cc-option to support clang

2018-11-23T07:20:35Z

commit c3f0d0bc5b01ad90c45276952802455750444b4f upstream. Clang will warn about unknown warnings but will not return false unless -Werror is set. GCC will return false if an unknown warning is passed. Adding -Werror make both compiler behave the same. [arnd: it turns out we need the same patch for testing whether -ffunction-sections works right with gcc. I've build tested extensively with this patch applied, so let's just merge this one now.] Signed-off-by: Mark Charlebois Signed-off-by: Behan Webster Reviewed-by: Jan-Simon Möller Signed-off-by: Arnd Bergmann Acked-by: Kees Cook Signed-off-by: Masahiro Yamada Signed-off-by: Nick Desaulniers Signed-off-by: Greg Kroah-Hartman

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