- 31 Jul, 2021 1 commit
-
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20210729135137.336097792@linuxfoundation.org Tested-by:
Jon Hunter <jonathanh@nvidia.com> Tested-by:
Shuah Khan <skhan@linuxfoundation.org> Tested-by:
Florian Fainelli <f.fainelli@gmail.com> Tested-by:
Linux Kernel Functional Testing <lkft@linaro.org> Tested-by:
Justin M. Forbes <jforbes@fedoraproject.org> Tested-by:
Guenter Roeck <linux@roeck-us.net> Tested-by:
Fox Chen <foxhlchen@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 28 Jul, 2021 1 commit
-
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20210726153846.245305071@linuxfoundation.org Tested-by:
Justin M. Forbes <jforbes@fedoraproject.org> Tested-by:
Florian Fainelli <f.fainelli@gmail.com> Tested-by:
Shuah Khan <skhan@linuxfoundation.org> Link: https://lore.kernel.org/r/20210726165238.919699741@linuxfoundation.org Tested-by:
Linux Kernel Functional Testing <lkft@linaro.org> Tested-by:
Jon Hunter <jonathanh@nvidia.com> Tested-by:
Guenter Roeck <linux@roeck-us.net> Tested-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 25 Jul, 2021 2 commits
-
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20210722155628.371356843@linuxfoundation.org Tested-by:
Jon Hunter <jonathanh@nvidia.com> Tested-by:
Shuah Khan <skhan@linuxfoundation.org> Tested-by:
Florian Fainelli <f.fainelli@gmail.com> Tested-by:
Guenter Roeck <linux@roeck-us.net> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Masahiro Yamada authored
commit d952cfaf upstream. When a new CONFIG option is available, Kbuild shows a prompt to get the user input. $ make [ snip ] Core Scheduling for SMT (SCHED_CORE) [N/y/?] (NEW) This is the only interactive place in the build process. Commit 174a1dcc ("kbuild: sink stdout from cmd for silent build") suppressed Kconfig prompts as well because syncconfig is invoked by the 'cmd' macro. You cannot notice the fact that Kconfig is waiting for the user input. Use 'kecho' to show the equivalent short log without suppressing stdout from sub-make. Fixes: 174a1dcc ("kbuild: sink stdout from cmd for silent build") Reported-by:
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org> Tested-by:
Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 20 Jul, 2021 2 commits
-
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20210719144944.537151528@linuxfoundation.org Tested-by:
Fox Chen <foxhlchen@gmail.com> Link: https://lore.kernel.org/r/20210719184345.989046417@linuxfoundation.org Tested-by:
Fox Chen <foxhlchen@gmail.com> Tested-by:
Shuah Khan <skhan@linuxfoundation.org> Tested-by:
Jon Hunter <jonathanh@nvidia.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Masahiro Yamada authored
[ Upstream commit 74ee585b ] M= (or KBUILD_EXTMOD) generally expects a directory path without any trailing slashes, like M=a/b/c. If you add a trailing slash, like M=a/b/c/, you will get ugly build logs (two slashes in a series), but it still works fine as long as it is consistent between 'make modules' and 'make modules_install'. The following commands correctly build and install the modules. $ make M=a/b/c/ modules $ sudo make M=a/b/c/ modules_install Since commit ccae4cfa ("kbuild: refactor scripts/Makefile.modinst"), a problem happens if you add a trailing slash only for modules_install. $ make M=a/b/c modules $ sudo make M=a/b/c/ modules_install No module is installed in this case, Johannes Berg reported. [1] Trim any trailing slashes from $(KBUILD_EXTMOD). I used the 'dirname' command to remove all the trailing slashes in case someone adds more slashes like M=a/b/c/////. The Make's built-in function, $(dir ...) cannot take care of such a case. [1]: https://lore.kernel.org/lkml/10cc8522b27a051e6a9c3e158a4c4b6414fd04a0.camel@sipsolutions.net/ Fixes: ccae4cfa ("kbuild: refactor scripts/Makefile.modinst") Reported-by:
Johannes Berg <johannes@sipsolutions.net> Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
- 19 Jul, 2021 1 commit
-
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20210715182613.933608881@linuxfoundation.org Tested-by:
Florian Fainelli <f.fainelli@gmail.com> Tested-by:
Jon Hunter <jonathanh@nvidia.com> Link: https://lore.kernel.org/r/20210716182150.239646976@linuxfoundation.org Tested-by:
Shuah Khan <skhan@linuxfoundation.org> Tested-by:
Jon Hunter <jonathanh@nvidia.com> Tested-by:
Fox Chen <foxhlchen@gmail.com> Tested-by:
Linux Kernel Functional Testing <lkft@linaro.org> Tested-by:
Guenter Roeck <linux@roeck-us.net> Tested-by:
Florian Fainelli <f.fainelli@gmail.com> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 14 Jul, 2021 2 commits
-
-
Greg Kroah-Hartman authored
Link: https://lore.kernel.org/r/20210712060912.995381202@linuxfoundation.org Tested-by:
Jon Hunter <jonathanh@nvidia.com> Tested-by:
Fox Chen <foxhlchen@gmail.com> Tested-by:
Florian Fainelli <f.fainelli@gmail.com> Tested-by:
Guenter Roeck <linux@roeck-us.net> Tested-by:
Shuah Khan <skhan@linuxfoundation.org> Tested-by:
Linux Kernel Functional Testing <lkft@linaro.org> Tested-by:
Justin M. Forbes <jforbes@fedoraproject.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Nick Desaulniers authored
[ Upstream commit 27f2a4db ] GDB produces the following warning when debugging kernels built with CONFIG_RELR: BFD: /android0/linux-next/vmlinux: unknown type [0x13] section `.relr.dyn' when loading a kernel built with CONFIG_RELR into GDB. It can also prevent debugging symbols using such relocations. Peter sugguests: [That flag] means that lld will use dynamic tags and section type numbers in the OS-specific range rather than the generic range. The kernel itself doesn't care about these numbers; it determines the location of the RELR section using symbols defined by a linker script. Link: https://github.com/ClangBuiltLinux/linux/issues/1057 Suggested-by:
Peter Collingbourne <pcc@google.com> Reviewed-by:
Nathan Chancellor <nathan@kernel.org> Signed-off-by:
Nick Desaulniers <ndesaulniers@google.com> Link: https://lore.kernel.org/r/20210522012626.2811297-1-ndesaulniers@google.com Signed-off-by:
Will Deacon <will@kernel.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
- 07 Jul, 2021 1 commit
-
-
Sasha Levin authored
Tested-by:
Fox Chen <foxhlchen@gmail.com> Tested-by:
Guenter Roeck <linux@roeck-us.net> Tested-by:
Linux Kernel Functional Testing <lkft@linaro.org> Tested-by:
Shuah Khan <skhan@linuxfoundation.org> Signed-off-by:
Sasha Levin <sashal@kernel.org>
-
- 27 Jun, 2021 1 commit
-
-
Linus Torvalds authored
-
- 20 Jun, 2021 1 commit
-
-
Linus Torvalds authored
-
- 14 Jun, 2021 1 commit
-
-
Tor Vic authored
Since LLVM commit fc018eb, the '-warn-stack-size' flag has been dropped [1], leading to the following error message when building with Clang-13 and LLD-13: ld.lld: error: -plugin-opt=-: ld.lld: Unknown command line argument '-warn-stack-size=2048'. Try: 'ld.lld --help' ld.lld: Did you mean '--asan-stack=2048'? In the same way as with commit 2398ce80 ("x86, lto: Pass -stack-alignment only on LLD < 13.0.0") , make '-warn-stack-size' conditional on LLD < 13.0.0. [1] https://reviews.llvm.org/D103928 Fixes: 24845dcb ("Makefile: LTO: have linker check -Wframe-larger-than") Cc: stable@vger.kernel.org Link: https://github.com/ClangBuiltLinux/linux/issues/1377 Signed-off-by:
Tor Vic <torvic9@mailbox.org> Reviewed-by:
Nathan Chancellor <nathan@kernel.org> Reviewed-by:
Nick Desaulniers <ndesaulniers@google.com> Signed-off-by:
Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/7631bab7-a8ab-f884-ab54-f4198976125c@mailbox.org
-
- 13 Jun, 2021 1 commit
-
-
Linus Torvalds authored
-
- 06 Jun, 2021 1 commit
-
-
Linus Torvalds authored
-
- 30 May, 2021 1 commit
-
-
Linus Torvalds authored
-
- 24 May, 2021 1 commit
-
-
Nick Desaulniers authored
-Wframe-larger-than= requires stack frame information, which the frontend cannot provide. This diagnostic is emitted late during compilation once stack frame size is available. When building with LTO, the frontend simply lowers C to LLVM IR and does not have stack frame information, so it cannot emit this diagnostic. When the linker drives LTO, it restarts optimizations and lowers LLVM IR to object code. At that point, it has stack frame information but doesn't know to check for a specific max stack frame size. I consider this a bug in LLVM that we need to fix. There are some details we're working out related to LTO such as which value to use when there are multiple different values specified per TU, or how to propagate these to compiler synthesized routines properly, if at all. Until it's fixed, ensure we don't miss these. At that point we can wrap this in a compiler version guard or revert this based on the minimum support version of Clang. The error message is not generated during link: LTO vmlinux.o ld.lld: warning: stack size limit exceeded (8224) in foobarbaz Cc: Sami Tolvanen <samitolvanen@google.com> Reported-by:
Candle Sun <candlesea@gmail.com> Suggested-by:
Fangrui Song <maskray@google.com> Signed-off-by:
Nick Desaulniers <ndesaulniers@google.com> Signed-off-by:
Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20210312010942.1546679-1-ndesaulniers@google.com
-
- 23 May, 2021 1 commit
-
-
Linus Torvalds authored
-
- 16 May, 2021 1 commit
-
-
Linus Torvalds authored
-
- 09 May, 2021 1 commit
-
-
Linus Torvalds authored
-
- 05 May, 2021 3 commits
-
-
Masahiro Yamada authored
The supported targets for external modules are listed in the help target a few lines below. Let's not have duplicated information in two places. Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org>
-
Masahiro Yamada authored
'make tags' and friends create tag files in the top directory, but people may manually create tag files in sub-directories. Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org>
-
Masahiro Yamada authored
This reverts the old commit [1], which seems questionable to me. It claimed 'make distclean' could not remove editor backup files, but I believe KBUILD_OUTPUT or O= was set. When O= is given, Kbuild should always work against $(objtree). If O= is not given, $(objtree) and $(srctree) are the same, therefore $(srctree) is cleaned up. [1]: https://git.kernel.org/pub/scm/linux/kernel/git/history/history.git/commit/?id=dd47df980c02eb33833b2690b033c34fba2fa80d Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org>
-
- 03 May, 2021 1 commit
-
-
Masahiro Yamada authored
Commit 37744fee ("sh: remove sh5 support") removed the SUPERH64 support entirely. Remove the left-over code from the top Makefile. Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org> Acked-by:
Arnd Bergmann <arnd@arndb.de>
-
- 01 May, 2021 2 commits
-
-
Nathan Chancellor authored
Currently, -Wunused-but-set-variable is only supported by GCC so it is disabled unconditionally in a GCC only block (it is enabled with W=1). clang currently has its implementation for this warning in review so preemptively move this statement out of the GCC only block and wrap it with cc-disable-warning so that both compilers function the same. Cc: stable@vger.kernel.org Link: https://reviews.llvm.org/D100581 Signed-off-by:
Nathan Chancellor <nathan@kernel.org> Reviewed-by:
Nick Desaulniers <ndesaulniers@google.com> Tested-by:
Nick Desaulniers <ndesaulniers@google.com> Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org>
-
Masahiro Yamada authored
We maintain .gitignore and Makefiles so build artifacts are properly ignored by Git, and cleaned up by 'make clean'. However, the code is always changing; generated files are often moved to another directory, or removed when they become unnecessary. Such garbage files tend to be left over in the source tree because people usually git-pull without cleaning the tree. This is not only the noise for 'git status', but also a build issue in some cases. One solution is to remove a stale file like commit 223c24a7 ("kbuild: Automatically remove stale <linux/version.h> file") did. Such workaround should be removed after a while, but we forget about that if we scatter the workaround code in random places. So, this commit adds a new script to collect cleanings of stale files. As a start point, move the code in arch/arm/boot/compressed/Makefile into this script. Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org>
-
- 25 Apr, 2021 1 commit
-
-
Linus Torvalds authored
-
- 24 Apr, 2021 13 commits
-
-
Nathan Chancellor authored
Normally, invocations of $(HOSTCC) include $(KBUILD_HOSTLDFLAGS), which in turn includes $(HOSTLDFLAGS), which allows users to pass in their own flags when linking. However, the 'has_libelf' test does not, meaning that if a user requests a specific linker via HOSTLDFLAGS=-fuse-ld=..., it is not respected and the build might error. For example, if a user building with clang wants to use all of the LLVM tools without any GNU tools, they might remove all of the GNU tools from their system or PATH then build with $ make HOSTLDFLAGS=-fuse-ld=lld LLVM=1 LLVM_IAS=1 which says use all of the LLVM tools, the integrated assembler, and ld.lld for linking host executables. Without this change, the build will error because $(HOSTCC) uses its default linker, rather than the one requested via -fuse-ld=..., which is GNU ld in clang's case in a default configuration. error: Cannot generate ORC metadata for CONFIG_UNWINDER_ORC=y, please install libelf-dev, libelf-devel or elfutils-libelf-devel make[1]: *** [Makefile:1260: prepare-objtool] Error 1 Add $(KBUILD_HOSTLDFLAGS) to the 'has_libelf' test so that the linker choice is respected. Link: https://github.com/ClangBuiltLinux/linux/issues/479 Signed-off-by:
Nathan Chancellor <nathan@kernel.org> Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org>
-
Masahiro Yamada authored
scripts/Makefile.modsign is a subset of scripts/Makefile.modinst, and duplicates the code. Let's merge them. By the way, you do not need to run 'make modules_sign' explicitly because modules are signed as a part of 'make modules_install' when CONFIG_MODULE_SIG_ALL=y. If CONFIG_MODULE_SIG_ALL=n, mod_sign_cmd is set to 'true', so 'make modules_sign' is not functional. In my understanding, the reason of still keeping this is to handle corner cases like commit 64178cb6 ("builddeb: fix stripped module signatures if CONFIG_DEBUG_INFO and CONFIG_MODULE_SIG_ALL are set"). Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org>
-
Masahiro Yamada authored
Both mod_strip_cmd and mod_compress_cmd are only used in scripts/Makefile.modinst, hence there is no good reason to define them in the top Makefile. Move the relevant code to scripts/Makefile.modinst. Also, show separate log messages for each of install, strip, sign, and compress. Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org>
-
Masahiro Yamada authored
scripts/Makefile.modinst is ugly and weird in multiple ways; it specifies real files $(modules) as phony, makes directory manipulation needlessly too complicated. Clean up the Makefile code, and show the full path of installed modules in the log. Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org>
-
Masahiro Yamada authored
This seems to be useful in sub-make as well. As a preparation of exporting it, rename extmod-prefix to extmod_prefix because exported variables cannot contain hyphens. Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org> Reviewed-by:
Nick Desaulniers <ndesaulniers@google.com>
-
Masahiro Yamada authored
If there are multiple modules with the same name in the same external module tree, there is ambiguity about which one will be loaded, and very likely something odd is happening. Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org>
-
Masahiro Yamada authored
It is clearer to show the directory which depmod will work on. Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org>
-
Masahiro Yamada authored
If you attempt to build or install modules ('make modules(_install)' with CONFIG_MODULES disabled, you will get a clear error message, but nothing for external module builds. Factor out the modules and modules_install rules into the common part, so you will get the same error message when you try to build external modules with CONFIG_MODULES=n. Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org>
-
Masahiro Yamada authored
scripts/Makefile.modinst creates directories as needed. Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org>
-
Masahiro Yamada authored
The external module build shows the following warning if Module.symvers is missing in the kernel tree. WARNING: Symbol version dump "Module.symvers" is missing. Modules may not have dependencies or modversions. I think this is an important heads-up because the resulting modules may not work as expected. This happens when you did not build the entire kernel tree, for example, you might have prepared the minimal setups for external modules by 'make defconfig && make modules_preapre'. A problem is that 'make modules' creates Module.symvers even without vmlinux. In this case, that warning is suppressed since Module.symvers already exists in spite of its incomplete content. The incomplete (i.e. invalid) Module.symvers should not be created. This commit changes the second pass of modpost to dump symbols into modules-only.symvers. The final Module.symvers is created by concatenating vmlinux.symvers and modules-only.symvers if both exist. Module.symvers is supposed to collect symbols from both vmlinux and modules. It might be a bit confusing, and I am not quite sure if it is an official interface, but presumably it is difficult to rename it because some tools (e.g. kmod) parse it. Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org>
-
Masahiro Yamada authored
Documentation/process/changes.rst defines the minimum assembler version (binutils version), but we have never checked it in the build time. Kbuild never invokes 'as' directly because all assembly files in the kernel tree are *.S, hence must be preprocessed. I do not expect raw assembly source files (*.s) would be added to the kernel tree. Therefore, we always use $(CC) as the assembler driver, and commit aa824e0c ("kbuild: remove AS variable") removed 'AS'. However, we are still interested in the version of the assembler acting behind. As usual, the --version option prints the version string. $ as --version | head -n 1 GNU assembler (GNU Binutils for Ubuntu) 2.35.1 But, we do not have $(AS). So, we can add the -Wa prefix so that $(CC) passes --version down to the backing assembler. $ gcc -Wa,--version | head -n 1 gcc: fatal error: no input files compilation terminated. OK, we need to input something to satisfy gcc. $ gcc -Wa,--...
-
Masahiro Yamada authored
For simple text replacement, it is better to use a built-in function instead of sed if possible. You can save one process forking. I do not mean to replace all sed invocations because GNU Make itself does not support regular expression (unless you use guile). I just replaced simple ones. Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org>
-
Nathan Chancellor authored
When building with LLVM_IAS=1, there is no point to specifying '--prefix=' because that flag is only used to find GNU cross tools, which will not be used indirectly when using the integrated assembler. All of the tools are invoked directly from PATH or a full path specified via the command line, which does not depend on the value of '--prefix='. Sharing commands to reproduce issues becomes a little bit easier without a '--prefix=' value because that '--prefix=' value is specific to a user's machine due to it being an absolute path. Some further notes from Fangrui Song: clang can spawn GNU as (if -f?no-integrated-as is specified) and GNU objcopy (-f?no-integrated-as and -gsplit-dwarf and -g[123]). objcopy is only used for GNU as assembled object files. With integrated assembler, the object file streamer creates .o and .dwo simultaneously. With GNU as, two objcopy commands are needed to extract .debug*.dwo to .dwo files && another command to remove .debug*.dwo sections. A small consequence of this change (to keep things simple) is that '--prefix=' will always be specified now, even with a native build, when it was not before. This should not be an issue due to the way that the Makefile searches for the prefix (based on elfedit's location). This ends up improving the experience for host builds because PATH is better respected and matches GCC's behavior more closely. See the below thread for more details: https://lore.kernel.org/r/20210205213651.GA16907@Ryzen-5-4500U.localdomain/ Signed-off-by:
Nathan Chancellor <nathan@kernel.org> Signed-off-by:
Masahiro Yamada <masahiroy@kernel.org>
-