Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14 |
|
#
fd06e32e |
| 23-Jan-2024 |
Nathan Chancellor <nathan@kernel.org> |
um: Fix adding '-no-pie' for clang
commit 846cfbeed09b45d985079a9173cf390cc053715b upstream.
The kernel builds with -fno-PIE, so commit 883354afbc10 ("um: link vmlinux with -no-pie") added the comp
um: Fix adding '-no-pie' for clang
commit 846cfbeed09b45d985079a9173cf390cc053715b upstream.
The kernel builds with -fno-PIE, so commit 883354afbc10 ("um: link vmlinux with -no-pie") added the compiler linker flag '-no-pie' via cc-option because '-no-pie' was only supported in GCC 6.1.0 and newer.
While this works for GCC, this does not work for clang because cc-option uses '-c', which stops the pipeline right before linking, so '-no-pie' is unconsumed and clang warns, causing cc-option to fail just as it would if the option was entirely unsupported:
$ clang -Werror -no-pie -c -o /dev/null -x c /dev/null clang-16: error: argument unused during compilation: '-no-pie' [-Werror,-Wunused-command-line-argument]
A recent version of clang exposes this because it generates a relocation under '-mcmodel=large' that is not supported in PIE mode:
/usr/sbin/ld: init/main.o: relocation R_X86_64_32 against symbol `saved_command_line' can not be used when making a PIE object; recompile with -fPIE /usr/sbin/ld: failed to set dynamic section sizes: bad value clang: error: linker command failed with exit code 1 (use -v to see invocation)
Remove the cc-option check altogether. It is wasteful to invoke the compiler to check for '-no-pie' because only one supported compiler version does not support it, GCC 5.x (as it is supported with the minimum version of clang and GCC 6.1.0+). Use a combination of the gcc-min-version macro and CONFIG_CC_IS_CLANG to unconditionally add '-no-pie' with CONFIG_LD_SCRIPT_DYN=y, so that it is enabled with all compilers that support this. Furthermore, using gcc-min-version can help turn this back into
LINK-$(CONFIG_LD_SCRIPT_DYN) += -no-pie
when the minimum version of GCC is bumped past 6.1.0.
Cc: stable@vger.kernel.org Closes: https://github.com/ClangBuiltLinux/linux/issues/1982 Signed-off-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40 |
|
#
8f85f93b |
| 21-Jul-2023 |
Masahiro Yamada <masahiroy@kernel.org> |
um: use obj-y to descend into arch/um/*/
The single build rule does not work with the core-y syntax. [1]
Use the standard obj-y syntax.
[1]: https://lore.kernel.org/linux-kbuild/d57ba55f-20a3-b836
um: use obj-y to descend into arch/um/*/
The single build rule does not work with the core-y syntax. [1]
Use the standard obj-y syntax.
[1]: https://lore.kernel.org/linux-kbuild/d57ba55f-20a3-b836-783d-b49c8a161b6e@kernel.org/T/#m7bc402e1e038f00ebcf2e92ed7fcb8a52fc1ea44
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Tested-by: Jiri Slaby <jirislaby@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Tested-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Richard Weinberger <richard@nod.at>
show more ...
|
#
d32df108 |
| 21-Jul-2023 |
Masahiro Yamada <masahiroy@kernel.org> |
um: Hard-code the result of 'uname -s'
We rely on 'uname -s' returning 'Linux' because there are os-Linux/ directories, but no other os-*/.
Supporting a non-Linux host is unlikely to happen.
Let's
um: Hard-code the result of 'uname -s'
We rely on 'uname -s' returning 'Linux' because there are os-Linux/ directories, but no other os-*/.
Supporting a non-Linux host is unlikely to happen.
Let's hard-code 'Linux'.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Richard Weinberger <richard@nod.at>
show more ...
|
Revision tags: v6.1.39, v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33 |
|
#
a5a319ec |
| 06-Jun-2023 |
Kees Cook <keescook@chromium.org> |
um: Use HOST_DIR for mrproper
When HEADER_ARCH was introduced, the MRPROPER_FILES (then MRPROPER_DIRS) list wasn't adjusted, leaving SUBARCH as part of the path argument. This resulted in the "mrpro
um: Use HOST_DIR for mrproper
When HEADER_ARCH was introduced, the MRPROPER_FILES (then MRPROPER_DIRS) list wasn't adjusted, leaving SUBARCH as part of the path argument. This resulted in the "mrproper" target not cleaning up arch/x86/... when SUBARCH was specified. Since HOST_DIR is arch/$(HEADER_ARCH), use it instead to get the correct path.
Cc: Richard Weinberger <richard@nod.at> Cc: Anton Ivanov <anton.ivanov@cambridgegreys.com> Cc: Johannes Berg <johannes@sipsolutions.net> Cc: Azeem Shaikh <azeemshaikh38@gmail.com> Cc: linux-um@lists.infradead.org Fixes: 7bbe7204e937 ("um: merge Makefile-{i386,x86_64}") Cc: stable@vger.kernel.org Signed-off-by: Kees Cook <keescook@chromium.org> Link: https://lore.kernel.org/r/20230606222442.never.807-kees@kernel.org
show more ...
|
Revision tags: v6.1.32, v6.1.31, v6.1.30, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22, v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16, v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6 |
|
#
83e913f5 |
| 13-Jan-2023 |
Peter Foley <pefoley2@pefoley.com> |
um: Support LTO
Only a handful of changes are necessary to get it to work.
Signed-off-by: Peter Foley <pefoley2@pefoley.com> Signed-off-by: Richard Weinberger <richard@nod.at>
|
#
6aa56115 |
| 12-Jan-2023 |
Peter Foley <pefoley2@pefoley.com> |
um: Use CFLAGS_vmlinux
link-vmlinux.sh doesn't use LDFLAGS_vmlinux when linking the kernel for UML. Move the LDFLAGS_EXESTACK options into CFLAGS_vmlinux so they're actually respected.
e.g. /usr/li
um: Use CFLAGS_vmlinux
link-vmlinux.sh doesn't use LDFLAGS_vmlinux when linking the kernel for UML. Move the LDFLAGS_EXESTACK options into CFLAGS_vmlinux so they're actually respected.
e.g. /usr/lib/gcc/x86_64-pc-linux-gnu/12/../../../../x86_64-pc-linux-gnu/bin/ld: warning: .tmp_vmlinux.kallsyms3.o: missing .note.GNU-stack section implies executable stack /usr/lib/gcc/x86_64-pc-linux-gnu/12/../../../../x86_64-pc-linux-gnu/bin/ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker /usr/lib/gcc/x86_64-pc-linux-gnu/12/../../../../x86_64-pc-linux-gnu/bin/ld: warning: vmlinux has a LOAD segment with RWX permissions
Reviewed-by: David Gow <davidgow@google.com> Signed-off-by: Peter Foley <pefoley2@pefoley.com> Signed-off-by: Richard Weinberger <richard@nod.at>
show more ...
|
Revision tags: v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14 |
|
#
905a7707 |
| 16-Dec-2022 |
David Gow <davidgow@google.com> |
rust: arch/um: Use 'pie' relocation mode under UML
UML expects a position independent executable for some reason, so tell rustc to generate pie objects. Otherwise we get a bunch of relocations we ca
rust: arch/um: Use 'pie' relocation mode under UML
UML expects a position independent executable for some reason, so tell rustc to generate pie objects. Otherwise we get a bunch of relocations we can't deal with in libcore.
Signed-off-by: David Gow <davidgow@google.com> Signed-off-by: Richard Weinberger <richard@nod.at>
show more ...
|
Revision tags: v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70 |
|
#
bd71558d |
| 21-Sep-2022 |
David Gow <davidgow@google.com> |
arch: um: Mark the stack non-executable to fix a binutils warning
Since binutils 2.39, ld will print a warning if any stack section is executable, which is the default for stack sections on files wi
arch: um: Mark the stack non-executable to fix a binutils warning
Since binutils 2.39, ld will print a warning if any stack section is executable, which is the default for stack sections on files without a .note.GNU-stack section.
This was fixed for x86 in commit ffcf9c5700e4 ("x86: link vdso and boot with -z noexecstack --no-warn-rwx-segments"), but remained broken for UML, resulting in several warnings:
/usr/bin/ld: warning: arch/x86/um/vdso/vdso.o: missing .note.GNU-stack section implies executable stack /usr/bin/ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker /usr/bin/ld: warning: .tmp_vmlinux.kallsyms1 has a LOAD segment with RWX permissions /usr/bin/ld: warning: .tmp_vmlinux.kallsyms1.o: missing .note.GNU-stack section implies executable stack /usr/bin/ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker /usr/bin/ld: warning: .tmp_vmlinux.kallsyms2 has a LOAD segment with RWX permissions /usr/bin/ld: warning: .tmp_vmlinux.kallsyms2.o: missing .note.GNU-stack section implies executable stack /usr/bin/ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker /usr/bin/ld: warning: vmlinux has a LOAD segment with RWX permissions
Link both the VDSO and vmlinux with -z noexecstack, fixing the warnings about .note.GNU-stack sections. In addition, pass --no-warn-rwx-segments to dodge the remaining warnings about LOAD segments with RWX permissions in the kallsyms objects. (Note that this flag is apparently not available on lld, so hide it behind a test for BFD, which is what the x86 patch does.)
Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ffcf9c5700e49c0aee42dcba9a12ba21338e8136 Link: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=ba951afb99912da01a6e8434126b8fac7aa75107 Signed-off-by: David Gow <davidgow@google.com> Reviewed-by: Lukas Straub <lukasstraub2@web.de> Tested-by: Lukas Straub <lukasstraub2@web.de> Acked-by: Randy Dunlap <rdunlap@infradead.org> # build-tested Signed-off-by: Richard Weinberger <richard@nod.at>
show more ...
|
Revision tags: v5.15.69, v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64, v5.15.63, v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49, v5.15.48, v5.15.47, v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39, v5.15.38, v5.15.37, v5.15.36, v5.15.35, v5.15.34, v5.15.33 |
|
#
1e39036d |
| 30-Mar-2022 |
Nathan Chancellor <nathan@kernel.org> |
Revert "um: clang: Strip out -mno-global-merge from USER_CFLAGS"
This reverts commit 6580c5c18fb3df2b11c5e0452372f815deeff895.
This patch is buggy, as noted in the patch linked below. The root caus
Revert "um: clang: Strip out -mno-global-merge from USER_CFLAGS"
This reverts commit 6580c5c18fb3df2b11c5e0452372f815deeff895.
This patch is buggy, as noted in the patch linked below. The root cause has been solved by removing '-mno-global-merge' for the entire kernel.
Link: https://lore.kernel.org/r/20220322173547.677760-1-nathan@kernel.org/ Signed-off-by: Nathan Chancellor <nathan@kernel.org> Reviewed-by: David Gow <davidgow@google.com> Reviewed-by: Kees Cook <keescook@chromium.org> Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
show more ...
|
Revision tags: v5.15.32, v5.15.31, v5.17, v5.15.30, v5.15.29, v5.15.28, v5.15.27 |
|
#
6580c5c1 |
| 03-Mar-2022 |
David Gow <davidgow@google.com> |
um: clang: Strip out -mno-global-merge from USER_CFLAGS
The things built with USER_CFLAGS don't seem to recognise it as a compiler option, and print a warning: clang: warning: argument unused during
um: clang: Strip out -mno-global-merge from USER_CFLAGS
The things built with USER_CFLAGS don't seem to recognise it as a compiler option, and print a warning: clang: warning: argument unused during compilation: '-mno-global-merge' [-Wunused-command-line-argument]
Fixes: 744814d2fa ("um: Allow builds with Clang") Signed-off-by: David Gow <davidgow@google.com> Reviewed-by: Nathan Chancellor <nathan@kernel.org> Signed-off-by: Richard Weinberger <richard@nod.at>
show more ...
|
#
005e368a |
| 21-Sep-2022 |
David Gow <davidgow@google.com> |
arch: um: Mark the stack non-executable to fix a binutils warning
[ Upstream commit bd71558d585ac61cfd799db7f25e78dca404dd7a ]
Since binutils 2.39, ld will print a warning if any stack section is e
arch: um: Mark the stack non-executable to fix a binutils warning
[ Upstream commit bd71558d585ac61cfd799db7f25e78dca404dd7a ]
Since binutils 2.39, ld will print a warning if any stack section is executable, which is the default for stack sections on files without a .note.GNU-stack section.
This was fixed for x86 in commit ffcf9c5700e4 ("x86: link vdso and boot with -z noexecstack --no-warn-rwx-segments"), but remained broken for UML, resulting in several warnings:
/usr/bin/ld: warning: arch/x86/um/vdso/vdso.o: missing .note.GNU-stack section implies executable stack /usr/bin/ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker /usr/bin/ld: warning: .tmp_vmlinux.kallsyms1 has a LOAD segment with RWX permissions /usr/bin/ld: warning: .tmp_vmlinux.kallsyms1.o: missing .note.GNU-stack section implies executable stack /usr/bin/ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker /usr/bin/ld: warning: .tmp_vmlinux.kallsyms2 has a LOAD segment with RWX permissions /usr/bin/ld: warning: .tmp_vmlinux.kallsyms2.o: missing .note.GNU-stack section implies executable stack /usr/bin/ld: NOTE: This behaviour is deprecated and will be removed in a future version of the linker /usr/bin/ld: warning: vmlinux has a LOAD segment with RWX permissions
Link both the VDSO and vmlinux with -z noexecstack, fixing the warnings about .note.GNU-stack sections. In addition, pass --no-warn-rwx-segments to dodge the remaining warnings about LOAD segments with RWX permissions in the kallsyms objects. (Note that this flag is apparently not available on lld, so hide it behind a test for BFD, which is what the x86 patch does.)
Link: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ffcf9c5700e49c0aee42dcba9a12ba21338e8136 Link: https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=ba951afb99912da01a6e8434126b8fac7aa75107 Signed-off-by: David Gow <davidgow@google.com> Reviewed-by: Lukas Straub <lukasstraub2@web.de> Tested-by: Lukas Straub <lukasstraub2@web.de> Acked-by: Randy Dunlap <rdunlap@infradead.org> # build-tested Signed-off-by: Richard Weinberger <richard@nod.at> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v5.15.26, v5.15.25, v5.15.24, v5.15.23, v5.15.22, v5.15.21, v5.15.20, v5.15.19, v5.15.18, v5.15.17, v5.4.173, v5.15.16, v5.15.15, v5.16, v5.15.10, v5.15.9, v5.15.8, v5.15.7, v5.15.6, v5.15.5, v5.15.4, v5.15.3, v5.15.2, v5.15.1, v5.15, v5.14.14, v5.14.13, v5.14.12, v5.14.11, v5.14.10, v5.14.9, v5.14.8, v5.14.7, v5.14.6, v5.10.67, v5.10.66, v5.14.5, v5.14.4, v5.10.65, v5.14.3, v5.10.64, v5.14.2, v5.10.63, v5.14.1, v5.10.62, v5.14, v5.10.61, v5.10.60, v5.10.53 |
|
#
d8285639 |
| 24-Jul-2021 |
Masahiro Yamada <masahiroy@kernel.org> |
kbuild: do not require sub-make for separate output tree builds
As explained in commit 3204a7fb98a3 ("kbuild: prefix $(srctree)/ to some included Makefiles"), I want to stop using --include-dir some
kbuild: do not require sub-make for separate output tree builds
As explained in commit 3204a7fb98a3 ("kbuild: prefix $(srctree)/ to some included Makefiles"), I want to stop using --include-dir some day.
I already fixed up the top Makefile, but some arch Makefiles (mips, um, x86) still include check-in Makefiles without $(srctree)/.
Fix them up so 'need-sub-make := 1' can go away for this case.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
show more ...
|
Revision tags: v5.10.52, v5.10.51, v5.10.50, v5.10.49, v5.13, v5.10.46, v5.10.43, v5.10.42, v5.10.41, v5.10.40, v5.10.39, v5.4.119, v5.10.36, v5.10.35, v5.10.34, v5.4.116, v5.10.33, v5.12, v5.10.32, v5.10.31, v5.10.30, v5.10.27, v5.10.26, v5.10.25, v5.10.24, v5.10.23, v5.10.22 |
|
#
386093c6 |
| 08-Mar-2021 |
Johannes Berg <johannes.berg@intel.com> |
um: allow not setting extra rpaths in the linux binary
There doesn't seem to be any reason for the rpath being set in the binaries, at on systems that I tested on. On the other hand, setting rpath i
um: allow not setting extra rpaths in the linux binary
There doesn't seem to be any reason for the rpath being set in the binaries, at on systems that I tested on. On the other hand, setting rpath is actually harming binaries in some cases, e.g. if using nix-based compilation environments where /lib & /lib64 are not part of the actual environment.
Add a new Kconfig option (under EXPERT, for less user confusion) that allows disabling the rpath additions.
Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Richard Weinberger <richard@nod.at>
show more ...
|
Revision tags: v5.10.21, v5.10.20, v5.10.19, v5.4.101, v5.10.18, v5.10.17, v5.11, v5.10.16, v5.10.15, v5.10.14, v5.10, v5.8.17, v5.8.16, v5.8.15, v5.9, v5.8.14, v5.8.13, v5.8.12, v5.8.11, v5.8.10, v5.8.9, v5.8.8, v5.8.7, v5.8.6, v5.4.62, v5.8.5, v5.8.4, v5.4.61, v5.8.3, v5.4.60, v5.8.2, v5.4.59, v5.8.1, v5.4.58, v5.4.57, v5.4.56, v5.8, v5.7.12, v5.4.55, v5.7.11, v5.4.54, v5.7.10, v5.4.53, v5.4.52, v5.7.9, v5.7.8, v5.4.51, v5.4.50, v5.7.7 |
|
#
893ab004 |
| 26-Jun-2020 |
Masahiro Yamada <masahiroy@kernel.org> |
kbuild: remove cc-option test of -fno-stack-protector
Some Makefiles already pass -fno-stack-protector unconditionally. For example, arch/arm64/kernel/vdso/Makefile, arch/x86/xen/Makefile.
No probl
kbuild: remove cc-option test of -fno-stack-protector
Some Makefiles already pass -fno-stack-protector unconditionally. For example, arch/arm64/kernel/vdso/Makefile, arch/x86/xen/Makefile.
No problem report so far about hard-coding this option. So, we can assume all supported compilers know -fno-stack-protector.
GCC 4.8 and Clang support this option (https://godbolt.org/z/_HDGzN)
Get rid of cc-option from -fno-stack-protector.
Remove CONFIG_CC_HAS_STACKPROTECTOR_NONE, which is always 'y'.
Note: arch/mips/vdso/Makefile adds -fno-stack-protector twice, first unconditionally, and second conditionally. I removed the second one.
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org> Reviewed-by: Kees Cook <keescook@chromium.org> Acked-by: Ard Biesheuvel <ardb@kernel.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com>
show more ...
|
Revision tags: v5.4.49, v5.7.6, v5.7.5, v5.4.48, v5.7.4, v5.7.3, v5.4.47, v5.4.46, v5.7.2, v5.4.45, v5.7.1, v5.4.44, v5.7, v5.4.43, v5.4.42, v5.4.41, v5.4.40, v5.4.39 |
|
#
0663c68c |
| 04-May-2020 |
Masahiro Yamada <masahiroy@kernel.org> |
kbuild: remove {CLEAN,MRPROPER,DISTCLEAN}_DIRS
Merge {CLEAN,MRPROPER,DISTCLEAN}_DIRS into {CLEAN,MRPROPER,DISTCLEAN}_FILES because the difference is just the -r option passed to the 'rm' command.
D
kbuild: remove {CLEAN,MRPROPER,DISTCLEAN}_DIRS
Merge {CLEAN,MRPROPER,DISTCLEAN}_DIRS into {CLEAN,MRPROPER,DISTCLEAN}_FILES because the difference is just the -r option passed to the 'rm' command.
Do likewise as commit 1634f2bfdb84 ("kbuild: remove clean-dirs syntax").
Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
show more ...
|
Revision tags: v5.4.38, v5.4.37, v5.4.36, v5.4.35 |
|
#
63ec90f1 |
| 21-Apr-2020 |
Vitor Massaru Iha <vitor@massaru.org> |
um: ensure `make ARCH=um mrproper` removes arch/$(SUBARCH)/include/generated/
In this workflow:
$ make ARCH=um defconfig && make ARCH=um -j8 [snip] $ make ARCH=um mrproper [snip] $ make ARCH=um
um: ensure `make ARCH=um mrproper` removes arch/$(SUBARCH)/include/generated/
In this workflow:
$ make ARCH=um defconfig && make ARCH=um -j8 [snip] $ make ARCH=um mrproper [snip] $ make ARCH=um defconfig O=./build_um && make ARCH=um -j8 O=./build_um [snip] CC scripts/mod/empty.o In file included from ../include/linux/types.h:6, from ../include/linux/mod_devicetable.h:12, from ../scripts/mod/devicetable-offsets.c:3: ../include/uapi/linux/types.h:5:10: fatal error: asm/types.h: No such file or directory 5 | #include <asm/types.h> | ^~~~~~~~~~~~~ compilation terminated. make[2]: *** [../scripts/Makefile.build:100: scripts/mod/devicetable-offsets.s] Error 1 make[2]: *** Waiting for unfinished jobs.... make[1]: *** [/home/iha/sdb/opensource/lkmp/linux-kselftest.git/Makefile:1140: prepare0] Error 2 make[1]: Leaving directory '/home/iha/sdb/opensource/lkmp/linux-kselftest.git/build_um' make: *** [Makefile:180: sub-make] Error 2
The cause of the error was because arch/$(SUBARCH)/include/generated files weren't properly cleaned by `make ARCH=um mrproper`.
Fixes: a788b2ed81ab ("kbuild: check arch/$(SRCARCH)/include/generated before out-of-tree build") Reported-by: Theodore Ts'o <tytso@mit.edu> Suggested-by: Masahiro Yamada <masahiroy@kernel.org> Signed-off-by: Vitor Massaru Iha <vitor@massaru.org> Reviewed-by: Brendan Higgins <brendanhiggins@google.com> Tested-by: Brendan Higgins <brendanhiggins@google.com> Link: https://groups.google.com/forum/#!msg/kunit-dev/QmA27YEgEgI/hvS1kiz2CwAJ Signed-off-by: Masahiro Yamada <masahiroy@kernel.org>
show more ...
|
Revision tags: v5.4.34, v5.4.33, v5.4.32, v5.4.31, v5.4.30, v5.4.29, v5.6, v5.4.28, v5.4.27, v5.4.26, v5.4.25, v5.4.24, v5.4.23, v5.4.22, v5.4.21, v5.4.20, v5.4.19, v5.4.18, v5.4.17, v5.4.16, v5.5, v5.4.15, v5.4.14, v5.4.13, v5.4.12, v5.4.11, v5.4.10, v5.4.9, v5.4.8, v5.4.7, v5.4.6, v5.4.5, v5.4.4, v5.4.3, v5.3.15, v5.4.2, v5.4.1, v5.3.14, v5.4, v5.3.13, v5.3.12, v5.3.11, v5.3.10, v5.3.9, v5.3.8, v5.3.7, v5.3.6, v5.3.5, v5.3.4, v5.3.3, v5.3.2, v5.3.1, v5.3, v5.2.14, v5.3-rc8, v5.2.13, v5.2.12, v5.2.11, v5.2.10, v5.2.9, v5.2.8, v5.2.7, v5.2.6, v5.2.5, v5.2.4, v5.2.3, v5.2.2, v5.2.1, v5.2 |
|
#
75dd4747 |
| 05-Jul-2019 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
kbuild: remove src and obj from the top Makefile
Replace $(src) and $(obj) with $(srctree) and $(objtree), respectively.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
Revision tags: v5.1.16, v5.1.15, v5.1.14, v5.1.13, v5.1.12, v5.1.11, v5.1.10, v5.1.9, v5.1.8, v5.1.7, v5.1.6, v5.1.5, v5.1.4, v5.1.3, v5.1.2, v5.1.1, v5.0.14, v5.1, v5.0.13, v5.0.12, v5.0.11, v5.0.10, v5.0.9, v5.0.8, v5.0.7, v5.0.6, v5.0.5, v5.0.4, v5.0.3, v4.19.29, v5.0.2, v4.19.28, v5.0.1, v4.19.27, v5.0, v4.19.26, v4.19.25, v4.19.24, v4.19.23, v4.19.22, v4.19.21, v4.19.20, v4.19.19, v4.19.18, v4.19.17, v4.19.16, v4.19.15, v4.19.14, v4.19.13, v4.19.12 |
|
#
733f4ef4 |
| 20-Dec-2018 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
um: remove unused filechk_gen_header in Makefile
This is a leftover of commit ecba97d4aacf ("[PATCH] uml makefiles sanitized").
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
|
Revision tags: v4.19.11, v4.19.10, v4.19.9, v4.19.8, v4.19.7, v4.19.6 |
|
#
65bba042 |
| 28-Nov-2018 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
kbuild: fix UML build error with CONFIG_GCC_PLUGINS
UML fails to build with CONFIG_GCC_PLUGINS=y.
$ make -s ARCH=um mrproper $ make -s ARCH=um allmodconfig $ make ARCH=um UPD include/generate
kbuild: fix UML build error with CONFIG_GCC_PLUGINS
UML fails to build with CONFIG_GCC_PLUGINS=y.
$ make -s ARCH=um mrproper $ make -s ARCH=um allmodconfig $ make ARCH=um UPD include/generated/uapi/linux/version.h WRAP arch/x86/include/generated/uapi/asm/bpf_perf_event.h WRAP arch/x86/include/generated/uapi/asm/poll.h WRAP arch/x86/include/generated/asm/dma-contiguous.h WRAP arch/x86/include/generated/asm/early_ioremap.h WRAP arch/x86/include/generated/asm/export.h WRAP arch/x86/include/generated/asm/mcs_spinlock.h WRAP arch/x86/include/generated/asm/mm-arch-hooks.h 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 SYSHDR arch/x86/include/generated/uapi/asm/unistd_32.h SYSHDR arch/x86/include/generated/uapi/asm/unistd_64.h SYSHDR arch/x86/include/generated/uapi/asm/unistd_x32.h HOSTCC scripts/unifdef CC arch/x86/um/user-offsets.s cc1: error: cannot load plugin ./scripts/gcc-plugins/cyc_complexity_plugin.so ./scripts/gcc-plugins/cyc_complexity_plugin.so: cannot open shared object file: No such file or directory cc1: error: cannot load plugin ./scripts/gcc-plugins/structleak_plugin.so ./scripts/gcc-plugins/structleak_plugin.so: cannot open shared object file: No such file or directory cc1: error: cannot load plugin ./scripts/gcc-plugins/latent_entropy_plugin.so ./scripts/gcc-plugins/latent_entropy_plugin.so: cannot open shared object file: No such file or directory cc1: error: cannot load plugin ./scripts/gcc-plugins/randomize_layout_plugin.so ./scripts/gcc-plugins/randomize_layout_plugin.so: cannot open shared object file: No such file or directory make[1]: *** [scripts/Makefile.build;119: arch/x86/um/user-offsets.s] Error 1 make: *** [arch/um/Makefile;152: arch/x86/um/user-offsets.s] Error 2
Reorder the preparation stage (with cleanups) to make sure gcc-plugins is built before descending to arch/x86/um/.
Fixes: 6b90bd4ba40b ("GCC plugin infrastructure") Reported-by: kbuild test robot <lkp@intel.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
show more ...
|
Revision tags: v4.19.5, v4.19.4, v4.18.20, v4.19.3, v4.18.19, v4.19.2, v4.18.18, v4.18.17, v4.19.1, v4.19, v4.18.16, v4.18.15, v4.18.14, v4.18.13, v4.18.12, v4.18.11, v4.18.10, v4.18.9, v4.18.7, v4.18.6, v4.18.5 |
|
#
d503ac53 |
| 23-Aug-2018 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
kbuild: rename LDFLAGS to KBUILD_LDFLAGS
Commit a0f97e06a43c ("kbuild: enable 'make CFLAGS=...' to add additional options to CC") renamed CFLAGS to KBUILD_CFLAGS.
Commit 222d394d30e7 ("kbuild: enab
kbuild: rename LDFLAGS to KBUILD_LDFLAGS
Commit a0f97e06a43c ("kbuild: enable 'make CFLAGS=...' to add additional options to CC") renamed CFLAGS to KBUILD_CFLAGS.
Commit 222d394d30e7 ("kbuild: enable 'make AFLAGS=...' to add additional options to AS") renamed AFLAGS to KBUILD_AFLAGS.
Commit 06c5040cdb13 ("kbuild: enable 'make CPPFLAGS=...' to add additional options to CPP") renamed CPPFLAGS to KBUILD_CPPFLAGS.
For some reason, LDFLAGS was not renamed.
Using a well-known variable like LDFLAGS may result in accidental override of the variable.
Kbuild generally uses KBUILD_ prefixed variables for the internally appended options, so here is one more conversion to sanitize the naming convention.
I did not touch Makefiles under tools/ since the tools build system is a different world.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com> Reviewed-by: Palmer Dabbelt <palmer@sifive.com>
show more ...
|
Revision tags: v4.17.18, v4.18.4, v4.18.3, v4.17.17, v4.18.2, v4.17.16, v4.17.15, v4.18.1, v4.18, v4.17.14, v4.17.13 |
|
#
0004438a |
| 03-Aug-2018 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
um: clean up archheaders recipe
Now that '%asm-generic' is added to no-dot-config-targets, 'make asm-generic' does not include the kernel configuration.
You can simply do 'make asm-generic' in the
um: clean up archheaders recipe
Now that '%asm-generic' is added to no-dot-config-targets, 'make asm-generic' does not include the kernel configuration.
You can simply do 'make asm-generic' in the recursed top Makefile without bothering syncconfig.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Tested-by: Randy Dunlap <rdunlap@infradead.org> Acked-by: Richard Weinberger <richard@nod.at>
show more ...
|
#
13d3d01e |
| 03-Aug-2018 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
um: fix parallel building with O= option
Randy Dunlap reports UML occasionally fails to build with -j<N> and O=<builddir> options.
make[1]: Entering directory '/home/rdunlap/mmotm-2018-0802-1529/
um: fix parallel building with O= option
Randy Dunlap reports UML occasionally fails to build with -j<N> and O=<builddir> options.
make[1]: Entering directory '/home/rdunlap/mmotm-2018-0802-1529/UM64' UPD include/generated/uapi/linux/version.h WRAP arch/x86/include/generated/asm/dma-contiguous.h WRAP arch/x86/include/generated/asm/export.h WRAP arch/x86/include/generated/asm/early_ioremap.h WRAP arch/x86/include/generated/asm/mcs_spinlock.h WRAP arch/x86/include/generated/asm/mm-arch-hooks.h WRAP arch/x86/include/generated/uapi/asm/bpf_perf_event.h WRAP arch/x86/include/generated/uapi/asm/poll.h GEN ./Makefile make[2]: *** No rule to make target 'archheaders'. Stop. arch/um/Makefile:119: recipe for target 'archheaders' failed make[1]: *** [archheaders] Error 2 make[1]: *** Waiting for unfinished jobs.... UPD include/config/kernel.release make[1]: *** wait: No child processes. Stop. Makefile:146: recipe for target 'sub-make' failed make: *** [sub-make] Error 2
The cause of the problem is the use of '$(MAKE) KBUILD_SRC=', which recurses to the top Makefile via the $(objtree)/Makefile generated by scripts/mkmakefile.
When you run "make -j<N> O=<builddir> ARCH=um", Make can execute 'archheaders' and 'outputmakefile' targets simultaneously because there is no dependency between them.
If it happens,
$(Q)$(MAKE) KBUILD_SRC= ARCH=$(HEADER_ARCH) archheaders
... tries to run $(objtree)/Makefile that is being updated.
The correct way for the recursion is
$(Q)$(MAKE) -f $(srctree)/Makefile ARCH=$(HEADER_ARCH) archheaders
..., which does not rely on the generated Makefile.
Reported-by: Randy Dunlap <rdunlap@infradead.org> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Tested-by: Randy Dunlap <rdunlap@infradead.org> Acked-by: Richard Weinberger <richard@nod.at>
show more ...
|
Revision tags: v4.17.12 |
|
#
79b05c1f |
| 31-Jul-2018 |
Christoph Hellwig <hch@lst.de> |
um: stop abusing KBUILD_KCONFIG
Instead create a arch/um/Kconfig file that just includes the actual per-arch Kconfig file. Note that we use HEADER_ARCH to find the per-arch Kconfig file as that var
um: stop abusing KBUILD_KCONFIG
Instead create a arch/um/Kconfig file that just includes the actual per-arch Kconfig file. Note that we use HEADER_ARCH to find the per-arch Kconfig file as that variable already includes the normalization from i386 or x86_64 to x86.
Signed-off-by: Christoph Hellwig <hch@lst.de> Acked-by: Richard Weinberger <richard@nod.at> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
show more ...
|
Revision tags: v4.17.11, v4.17.10 |
|
#
43fee2b2 |
| 25-Jul-2018 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
kbuild: do not redirect the first prerequisite for filechk
Currently, filechk unconditionally opens the first prerequisite and redirects it as the stdin of a filechk_* rule. Hence, every target usi
kbuild: do not redirect the first prerequisite for filechk
Currently, filechk unconditionally opens the first prerequisite and redirects it as the stdin of a filechk_* rule. Hence, every target using $(call filechk,...) must list something as the first prerequisite even if it is unneeded.
'< $<' is actually unneeded in most cases. Each rule can explicitly adds it if necessary.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
show more ...
|
Revision tags: v4.17.9, v4.17.8, v4.17.7, v4.17.6, v4.17.5, v4.17.4, v4.17.3, v4.17.2, v4.17.1, v4.17, v4.16, v4.15, v4.13.16, v4.14, v4.13.5 |
|
#
699d7a57 |
| 04-Sep-2017 |
Al Viro <viro@zeniv.linux.org.uk> |
um: make sure to have generated headers for target
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
|