summaryrefslogtreecommitdiff
path: root/Makefile
AgeCommit message (Collapse)Author
2019-11-29Linux 4.9.205v4.9.205Greg Kroah-Hartman
2019-11-28Linux 4.9.204v4.9.204Greg Kroah-Hartman
2019-11-25Linux 4.9.203v4.9.203Greg Kroah-Hartman
2019-11-16Linux 4.9.202v4.9.202Greg Kroah-Hartman
2019-11-12Linux 4.9.201v4.9.201Greg Kroah-Hartman
2019-11-10Linux 4.9.200v4.9.200Greg Kroah-Hartman
2019-11-10kbuild: add -fcf-protection=none when using retpoline flagsSeth Forshee
[ Upstream commit 29be86d7f9cb18df4123f309ac7857570513e8bc ] The gcc -fcf-protection=branch option is not compatible with -mindirect-branch=thunk-extern. The latter is used when CONFIG_RETPOLINE is selected, and this will fail to build with a gcc which has -fcf-protection=branch enabled by default. Adding -fcf-protection=none when building with retpoline enabled prevents such build failures. Signed-off-by: Seth Forshee <seth.forshee@canonical.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-11-10kbuild: use -fmacro-prefix-map to make __FILE__ a relative pathMasahiro Yamada
[ Upstream commit a73619a845d5625079cc1b3b820f44c899618388 ] The __FILE__ macro is used everywhere in the kernel to locate the file printing the log message, such as WARN_ON(), etc. If the kernel is built out of tree, this can be a long absolute path, like this: WARNING: CPU: 1 PID: 1 at /path/to/build/directory/arch/arm64/kernel/foo.c:... This is because Kbuild runs in the objtree instead of the srctree, then __FILE__ is expanded to a file path prefixed with $(srctree)/. Commit 9da0763bdd82 ("kbuild: Use relative path when building in a subdir of the source tree") improved this to some extent; $(srctree) becomes ".." if the objtree is a child of the srctree. For other cases of out-of-tree build, __FILE__ is still the absolute path. It also means the kernel image depends on where it was built. A brand-new option from GCC, -fmacro-prefix-map, solves this problem. If your compiler supports it, __FILE__ is the relative path from the srctree regardless of O= option. This provides more readable log and more reproducible builds. Please note __FILE__ is always an absolute path for external modules. Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-11-10Kbuild: make designated_init attribute fatalKees Cook
[ Upstream commit c834f0e8a8bb3025aac38e802fca2e686720f544 ] If a structure is marked with __attribute__((designated_init)) from GCC or Sparse, it needs to have all static initializers using designated initialization. Fail the build for any missing cases. This attribute will be used by the randstruct plugin to make sure randomized structures are being correctly initialized. Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-11-06Linux 4.9.199v4.9.199Greg Kroah-Hartman
2019-10-29Linux 4.9.198v4.9.198Greg Kroah-Hartman
2019-10-17Linux 4.9.197v4.9.197Greg Kroah-Hartman
2019-10-07Linux 4.9.196v4.9.196Greg Kroah-Hartman
2019-10-05Linux 4.9.195v4.9.195Greg Kroah-Hartman
2019-09-21Linux 4.9.194v4.9.194Greg Kroah-Hartman
2019-09-16Linux 4.9.193v4.9.193Greg Kroah-Hartman
2019-09-10Linux 4.9.192v4.9.192Greg Kroah-Hartman
2019-09-06Linux 4.9.191v4.9.191Greg Kroah-Hartman
2019-08-25Linux 4.9.190v4.9.190Greg Kroah-Hartman
2019-08-11Linux 4.9.189v4.9.189Greg Kroah-Hartman
2019-08-06Linux 4.9.188v4.9.188Greg Kroah-Hartman
2019-08-06kbuild: initialize CLANG_FLAGS correctly in the top MakefileMasahiro Yamada
commit 5241ab4cf42d3a93b933b55d3d53f43049081fa1 upstream. CLANG_FLAGS is initialized by the following line: CLANG_FLAGS := --target=$(notdir $(CROSS_COMPILE:%-=%)) ..., which is run only when CROSS_COMPILE is set. Some build targets (bindeb-pkg etc.) recurse to the top Makefile. When you build the kernel with Clang but without CROSS_COMPILE, the same compiler flags such as -no-integrated-as are accumulated into CLANG_FLAGS. If you run 'make CC=clang' and then 'make CC=clang bindeb-pkg', Kbuild will recompile everything needlessly due to the build command change. Fix this by correctly initializing CLANG_FLAGS. Fixes: 238bcbc4e07f ("kbuild: consolidate Clang compiler flags") Cc: <stable@vger.kernel.org> # v5.0+ Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Acked-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-08-04Linux 4.9.187v4.9.187Greg Kroah-Hartman
2019-08-04kbuild: Add -Werror=unknown-warning-option to CLANG_FLAGSNathan Chancellor
[ Upstream commit 589834b3a0097a4908f4112eac0ca2feb486fa32 ] In commit ebcc5928c5d9 ("arm64: Silence gcc warnings about arch ABI drift"), the arm64 Makefile added -Wno-psabi to KBUILD_CFLAGS, which is a GCC only option so clang rightfully complains: warning: unknown warning option '-Wno-psabi' [-Wunknown-warning-option] https://clang.llvm.org/docs/DiagnosticsReference.html#wunknown-warning-option However, by default, this is merely a warning so the build happily goes on with a slew of these warnings in the process. Commit c3f0d0bc5b01 ("kbuild, LLVMLinux: Add -Werror to cc-option to support clang") worked around this behavior in cc-option by adding -Werror so that unknown flags cause an error. However, this all happens silently and when an unknown flag is added to the build unconditionally like -Wno-psabi, cc-option will always fail because there is always an unknown flag in the list of flags. This manifested as link time failures in the arm64 libstub because -fno-stack-protector didn't get added to KBUILD_CFLAGS. To avoid these weird cryptic failures in the future, make clang behave like gcc and immediately error when it encounters an unknown flag by adding -Werror=unknown-warning-option to CLANG_FLAGS. This can be added unconditionally for clang because it is supported by at least 3.0.0, according to godbolt [1] and 4.0.0, according to its documentation [2], which is far earlier than we typically support. [1]: https://godbolt.org/z/7F7rm3 [2]: https://releases.llvm.org/4.0.0/tools/clang/docs/DiagnosticsReference.html#wunknown-warning-option Link: https://github.com/ClangBuiltLinux/linux/issues/511 Link: https://github.com/ClangBuiltLinux/linux/issues/517 Suggested-by: Peter Smith <peter.smith@linaro.org> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Tested-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-07-21Linux 4.9.186v4.9.186Greg Kroah-Hartman
2019-07-10Linux 4.9.185v4.9.185Greg Kroah-Hartman
2019-07-10gcc-9: silence 'address-of-packed-member' warningLinus Torvalds
commit 6f303d60534c46aa1a239f29c321f95c83dda748 upstream. We already did this for clang, but now gcc has that warning too. Yes, yes, the address may be unaligned. And that's kind of the point. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-27Linux 4.9.184v4.9.184Greg Kroah-Hartman
2019-06-22Linux 4.9.183v4.9.183Greg Kroah-Hartman
2019-06-17Linux 4.9.182v4.9.182Greg Kroah-Hartman
2019-06-11Linux 4.9.181v4.9.181Greg Kroah-Hartman
2019-05-31Linux 4.9.180v4.9.180Greg Kroah-Hartman
2019-05-25Linux 4.9.179v4.9.179Greg Kroah-Hartman
2019-05-21Linux 4.9.178v4.9.178Greg Kroah-Hartman
2019-05-16Linux 4.9.177v4.9.177Greg Kroah-Hartman
2019-05-14Linux 4.9.176v4.9.176Greg Kroah-Hartman
2019-05-10Linux 4.9.175v4.9.175Greg Kroah-Hartman
2019-05-08Linux 4.9.174v4.9.174Greg Kroah-Hartman
2019-05-04Linux 4.9.173v4.9.173Greg Kroah-Hartman
2019-05-02Linux 4.9.172v4.9.172Greg Kroah-Hartman
2019-04-27Linux 4.9.171v4.9.171Greg Kroah-Hartman
2019-04-27Revert "kbuild: use -Oz instead of -Os when using clang"Matthias Kaehlcke
commit a75bb4eb9e565b9f5115e2e8c07377ce32cbe69a upstream. The clang option -Oz enables *aggressive* optimization for size, which doesn't necessarily result in smaller images, but can have negative impact on performance. Switch back to the less aggressive -Os. This reverts commit 6748cb3c299de1ffbe56733647b01dbcc398c419. Suggested-by: Peter Zijlstra <peterz@infradead.org> Signed-off-by: Matthias Kaehlcke <mka@chromium.org> Reviewed-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-04-20Linux 4.9.170v4.9.170Greg Kroah-Hartman
2019-04-17Linux 4.9.169v4.9.169Greg Kroah-Hartman
2019-04-17kbuild: clang: choose GCC_TOOLCHAIN_DIR not on LDNick Desaulniers
commit ad15006cc78459d059af56729c4d9bed7c7fd860 upstream. This causes an issue when trying to build with `make LD=ld.lld` if ld.lld and the rest of your cross tools aren't in the same directory (ex. /usr/local/bin) (as is the case for Android's build system), as the GCC_TOOLCHAIN_DIR then gets set based on `which $(LD)` which will point where LLVM tools are, not GCC/binutils tools are located. Instead, select the GCC_TOOLCHAIN_DIR based on another tool provided by binutils for which LLVM does not provide a substitute for, such as elfedit. Fixes: 785f11aa595b ("kbuild: Add better clang cross build support") Link: https://github.com/ClangBuiltLinux/linux/issues/341 Suggested-by: Nathan Chancellor <natechancellor@gmail.com> Reviewed-by: Nathan Chancellor <natechancellor@gmail.com> Tested-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Nick Desaulniers <ndesaulniers@google.com> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: Nathan Chancellor <natechancellor@gmail.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
2019-04-05Linux 4.9.168v4.9.168Greg Kroah-Hartman
2019-04-03Linux 4.9.167v4.9.167Greg Kroah-Hartman
2019-03-27Linux 4.9.166v4.9.166Greg Kroah-Hartman
2019-03-23Linux 4.9.165v4.9.165Greg Kroah-Hartman
2019-03-19Linux 4.9.164v4.9.164Greg Kroah-Hartman