- 24 12月, 2018 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 19 12月, 2018 2 次提交
-
-
由 Masahiro Yamada 提交于
For the same reason as commit 25896d07 ("x86/build: Fix compiler support check for CONFIG_RETPOLINE"), you cannot put this $(error ...) into the parse stage of the top Makefile. Perhaps I'd propose a more sophisticated solution later, but this is the best I can do for now. Link: https://lkml.org/lkml/2017/12/25/211Reported-by: NPaul Gortmaker <paul.gortmaker@windriver.com> Reported-by: NBernd Edlinger <bernd.edlinger@hotmail.de> Reported-by: NQian Cai <cai@lca.pw> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com> Tested-by: NQian Cai <cai@lca.pw>
-
由 Ingo Molnar 提交于
Revert "kbuild/Makefile: Prepare for using macros in inline assembly code to work around asm() related GCC inlining bugs" This reverts commit 77b0bf55. See this commit for details about the revert: e769742d ("Revert "x86/jump-labels: Macrofy inline assembly code to work around GCC inlining bugs"") Conflicts: arch/x86/Makefile Reported-by: NMasahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: NBorislav Petkov <bp@alien8.de> Reviewed-by: NThomas Gleixner <tglx@linutronix.de> Cc: Juergen Gross <jgross@suse.com> Cc: Richard Biener <rguenther@suse.de> Cc: Kees Cook <keescook@chromium.org> Cc: Segher Boessenkool <segher@kernel.crashing.org> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Josh Poimboeuf <jpoimboe@redhat.com> Cc: Nadav Amit <namit@vmware.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: linux-kernel@vger.kernel.org Signed-off-by: NIngo Molnar <mingo@kernel.org>
-
- 17 12月, 2018 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 13 12月, 2018 1 次提交
-
-
由 Rob Herring 提交于
This adds the build infrastructure for checking DT binding schema documents and validating dts files using the binding schema. Check DT binding schema documents: make dt_binding_check Build dts files and check using DT binding schema: make dtbs_check Optionally, DT_SCHEMA_FILES can be passed in with a schema file(s) to use for validation. This makes it easier to find and fix errors generated by a specific schema. Currently, the validation targets are separate from a normal build to avoid a hard dependency on the external DT schema project and because there are lots of warnings generated. Cc: Jonathan Corbet <corbet@lwn.net> Cc: Mark Rutland <mark.rutland@arm.com> Acked-by: NMasahiro Yamada <yamada.masahiro@socionext.com> Cc: Michal Marek <michal.lkml@markovi.net> Cc: linux-doc@vger.kernel.org Cc: devicetree@vger.kernel.org Cc: linux-kbuild@vger.kernel.org Signed-off-by: NRob Herring <robh@kernel.org>
-
- 10 12月, 2018 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 03 12月, 2018 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 26 11月, 2018 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 19 11月, 2018 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 12 11月, 2018 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 05 11月, 2018 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 02 11月, 2018 2 次提交
-
-
由 Masahiro Yamada 提交于
There is one more user of $(cc-name) in the top Makefile. It is supposed to detect Clang before invoking Kconfig, so it should still be there in the $(shell ...) form. All the other users of $(cc-name) have been replaced with $(CONFIG_CC_IS_CLANG). Hence, scripts/Kbuild.include does not need to define cc-name any more. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
由 Masahiro Yamada 提交于
Evaluating cc-name invokes the compiler every time even when you are not compiling anything, like 'make help'. This is not efficient. The compiler type has been already detected in the Kconfig stage. Use CONFIG_CC_IS_CLANG, instead. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com> Acked-by: Michael Ellerman <mpe@ellerman.id.au> (powerpc) Acked-by: Paul Burton <paul.burton@mips.com> (MIPS) Acked-by: NJoel Stanley <joel@jms.id.au>
-
- 22 10月, 2018 1 次提交
-
-
由 Greg Kroah-Hartman 提交于
-
- 19 10月, 2018 3 次提交
-
-
由 Masahiro Yamada 提交于
We have raised the compiler requirement from time to time. With commit cafa0010 ("Raise the minimum required gcc version to 4.6"), the minimum for GCC is 4.6 now. This flag was added by GCC 4.6, and it is recognized by ICC as well. It is true that Clang does not support this flag but this commit is just touching the else part of the "ifeq ($(cc-name),clang)" check. Hence, Clang build is not affected. Let's rip off the cc-disable-warning switch, and see if somebody complains about it. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: NNick Desaulniers <ndesaulniers@google.com>
-
由 Masahiro Yamada 提交于
We have raised the compiler requirement from time to time. With commit cafa0010 ("Raise the minimum required gcc version to 4.6"), the minimum for GCC is 4.6 now. This flag has been here since the pre-git era. It is documented in the GCC 4.6 manual, and it is recognized by Clang and ICC as well. Let's rip off the cc-option switch, and see if somebody complains about it. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com> Tested-by: NNick Desaulniers <ndesaulniers@google.com>
-
由 Masahiro Yamada 提交于
We have raised the compiler requirement from time to time. With commit cafa0010 ("Raise the minimum required gcc version to 4.6"), the minimum for GCC is 4.6 now. The -Wno-pointer-sign has been here since the pre-git era. It is documented in the GCC 4.6 manual, and it is recognized by Clang and ICC as well. Let's rip off the cc-disable-warning switch, and see if somebody complains about it. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com> Tested-by: NNick Desaulniers <ndesaulniers@google.com>
-
- 15 10月, 2018 1 次提交
-
-
由 Greg Kroah-Hartman 提交于
-
- 11 10月, 2018 1 次提交
-
-
由 Kees Cook 提交于
Now that Variable Length Arrays (VLAs) have been entirely removed[1] from the kernel, enable the VLA warning globally. The only exceptions to this are the KASan an UBSan tests which are explicitly checking that VLAs trigger their respective tests. [1] https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qPXydAacU1RqZWA@mail.gmail.com Cc: Masahiro Yamada <yamada.masahiro@socionext.com> Cc: Andrew Morton <akpm@linux-foundation.org> Cc: David Airlie <airlied@linux.ie> Cc: linux-kbuild@vger.kernel.org Cc: intel-gfx@lists.freedesktop.org Cc: dri-devel@lists.freedesktop.org Signed-off-by: NKees Cook <keescook@chromium.org>
-
- 07 10月, 2018 1 次提交
-
-
由 Greg Kroah-Hartman 提交于
-
- 04 10月, 2018 4 次提交
-
-
由 Masahiro Yamada 提交于
Since $(objtree) is always '.', it is not useful to pass it to scripts/mkmakefile. I assume nobody wants to run this script directly. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
由 Masahiro Yamada 提交于
Neither VERSION nor PATCHLEVEL is used in any useful way. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
由 Masahiro Yamada 提交于
The --include-dir flag is used to include check-in Makefiles from $(objtree) without $(srctree)/ prefix. Obviously, this is unneeded for in-tree build. Add the flag just before changing the working directory. This becomes effective after invoking sub-make. Add a little bit comments about it. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
由 Nadav Amit 提交于
kbuild/Makefile: Prepare for using macros in inline assembly code to work around asm() related GCC inlining bugs Using macros in inline assembly allows us to work around bugs in GCC's inlining decisions. Compile macros.S and use it to assemble all C files. Currently only x86 will use it. Background: The inlining pass of GCC doesn't include an assembler, so it's not aware of basic properties of the generated code, such as its size in bytes, or that there are such things as discontiuous blocks of code and data due to the newfangled linker feature called 'sections' ... Instead GCC uses a lazy and fragile heuristic: it does a linear count of certain syntactic and whitespace elements in inlined assembly block source code, such as a count of new-lines and semicolons (!), as a poor substitute for "code size and complexity". Unsurprisingly this heuristic falls over and breaks its neck whith certain common types of kernel code that use inline assembly, such as the frequent practice of putting useful information into alternative sections. As a result of this fresh, 20+ years old GCC bug, GCC's inlining decisions are effectively disabled for inlined functions that make use of such asm() blocks, because GCC thinks those sections of code are "large" - when in reality they are often result in just a very low number of machine instructions. This absolute lack of inlining provess when GCC comes across such asm() blocks both increases generated kernel code size and causes performance overhead, which is particularly noticeable on paravirt kernels, which make frequent use of these inlining facilities in attempt to stay out of the way when running on baremetal hardware. Instead of fixing the compiler we use a workaround: we set an assembly macro and call it from the inlined assembly block. As a result GCC considers the inline assembly block as a single instruction. (Which it often isn't but I digress.) This uglifies and bloats the source code - for example just the refcount related changes have this impact: Makefile | 9 +++++++-- arch/x86/Makefile | 7 +++++++ arch/x86/kernel/macros.S | 7 +++++++ scripts/Kbuild.include | 4 +++- scripts/mod/Makefile | 2 ++ 5 files changed, 26 insertions(+), 3 deletions(-) Yay readability and maintainability, it's not like assembly code is hard to read and maintain ... We also hope that GCC will eventually get fixed, but we are not holding our breath for that. Yet we are optimistic, it might still happen, any decade now. [ mingo: Wrote new changelog describing the background. ] Tested-by: NKees Cook <keescook@chromium.org> Signed-off-by: NNadav Amit <namit@vmware.com> Acked-by: NMasahiro Yamada <yamada.masahiro@socionext.com> Acked-by: NPeter Zijlstra (Intel) <peterz@infradead.org> Cc: Andy Lutomirski <luto@amacapital.net> Cc: Borislav Petkov <bp@alien8.de> Cc: Brian Gerst <brgerst@gmail.com> Cc: Denys Vlasenko <dvlasenk@redhat.com> Cc: H. Peter Anvin <hpa@zytor.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Michal Marek <michal.lkml@markovi.net> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Sam Ravnborg <sam@ravnborg.org> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: linux-kbuild@vger.kernel.org Link: http://lkml.kernel.org/r/20181003213100.189959-3-namit@vmware.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
-
- 02 10月, 2018 1 次提交
-
-
由 Rob Herring 提交于
There is nothing arch specific about building dtb files other than their location under /arch/*/boot/dts/. Keeping each arch aligned is a pain. The dependencies and supported targets are all slightly different. Also, a cross-compiler for each arch is needed, but really the host compiler preprocessor is perfectly fine for building dtbs. Move the build rules to a common location and remove the arch specific ones. This is done in a single step to avoid warnings about overriding rules. The build dependencies had been a mixture of 'scripts' and/or 'prepare'. These pull in several dependencies some of which need a target compiler (specifically devicetable-offsets.h) and aren't needed to build dtbs. All that is really needed is dtc, so adjust the dependencies to only be dtc. This change enables support 'dtbs_install' on some arches which were missing the target. Acked-by: NWill Deacon <will.deacon@arm.com> Acked-by: NPaul Burton <paul.burton@mips.com> Acked-by: NLey Foon Tan <ley.foon.tan@intel.com> Acked-by: NMasahiro Yamada <yamada.masahiro@socionext.com> Cc: Michal Marek <michal.lkml@markovi.net> Cc: Vineet Gupta <vgupta@synopsys.com> Cc: Russell King <linux@armlinux.org.uk> Cc: Catalin Marinas <catalin.marinas@arm.com> Cc: Yoshinori Sato <ysato@users.sourceforge.jp> Cc: Michal Simek <monstr@monstr.eu> Cc: Ralf Baechle <ralf@linux-mips.org> Cc: James Hogan <jhogan@kernel.org> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org> Cc: Paul Mackerras <paulus@samba.org> Cc: Michael Ellerman <mpe@ellerman.id.au> Cc: Chris Zankel <chris@zankel.net> Cc: Max Filippov <jcmvbkbc@gmail.com> Cc: linux-kbuild@vger.kernel.org Cc: linux-snps-arc@lists.infradead.org Cc: linux-arm-kernel@lists.infradead.org Cc: uclinux-h8-devel@lists.sourceforge.jp Cc: linux-mips@linux-mips.org Cc: nios2-dev@lists.rocketboards.org Cc: linuxppc-dev@lists.ozlabs.org Cc: linux-xtensa@linux-xtensa.org Signed-off-by: NRob Herring <robh@kernel.org>
-
- 30 9月, 2018 1 次提交
-
-
由 Greg Kroah-Hartman 提交于
-
- 24 9月, 2018 1 次提交
-
-
由 Greg Kroah-Hartman 提交于
-
- 19 9月, 2018 1 次提交
-
-
由 Stefan Agner 提交于
When using a GCC cross toolchain which is not in a compiled in Clang search path, Clang reverts to the system assembler and linker. This leads to assembler or linker errors, depending on which tool is first used for a given architecture. It seems that Clang is not searching $PATH for a matching assembler or linker. Make sure that Clang picks up the correct assembler or linker by passing the cross compilers bin directory as search path. This allows to use Clang provided by distributions with GCC toolchains not in /usr/bin. Link: https://github.com/ClangBuiltLinux/linux/issues/78Signed-off-by: NStefan Agner <stefan@agner.ch> Reviewed-and-tested-by: NNick Desaulniers <ndesaulniers@google.com> Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
- 17 9月, 2018 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 14 9月, 2018 2 次提交
-
-
由 Masahiro Yamada 提交于
Nobody sets 'targets' in the top-level Makefile or arch/*/Makefile, hence $(targets) is empty. $(wildcard .*.cmd) will do for including the .vmlinux.cmd file. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
由 Masahiro Yamada 提交于
When mixed/config targets are being processed, the top Makefile does not need to parse the rest of targets. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
- 13 9月, 2018 1 次提交
-
-
由 Paulo Zanoni 提交于
As a Kernel developer, I make heavy use of "make targz-pkg" in order to locally compile and remotely install my development Kernels. The nice feature I rely on is that after a normal "make", "make targz-pkg" only generates the tarball without having to recompile everything. That was true until commit f28bc3c3 ("tracing: Handle CC_FLAGS_FTRACE more accurately"). After it, running "make targz-pkg" after "make" will recompile the whole Kernel tree, making my development workflow much slower. The Kernel is choosing to recompile everything because it claims the command line has changed. A diff of the .cmd files show a repeated -mfentry in one of the files. That is because "make targz-pkg" calls "make modules_install" and the environment is already populated with the exported variables, CC_FLAGS_FTRACE being one of them. Then, -mfentry gets duplicated because it is not protected behind an ifndef block, like -pg. To complicate the problem a little bit more, architectures can define their own version CC_FLAGS_FTRACE, so our code not only has to consider recursive Makefiles, but also architecture overrides. So in this patch we move CC_FLAGS_FTRACE up and unconditionally define it to -pg. Then we let the architecture Makefiles possibly override it, and finally append the extra options later. This ensures the variable is always fully redefined at each invocation so recursive Makefiles don't keep appending, and hopefully it maintains the intended behavior on how architectures can override the defaults.. Thanks Steven Rostedt and Vasily Gorbik for the help on this regression. Cc: Michal Marek <michal.lkml@markovi.net> Cc: Ingo Molnar <mingo@redhat.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: linux-kbuild@vger.kernel.org Fixes: commit f28bc3c3 ("tracing: Handle CC_FLAGS_FTRACE more accurately") Acked-by: NVasily Gorbik <gor@linux.ibm.com> Signed-off-by: NPaulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
-
- 10 9月, 2018 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 05 9月, 2018 1 次提交
-
-
由 Anders Roxell 提交于
If the kernel headers aren't installed we can't build all the tests. Add a new make target rule 'khdr' in the file lib.mk to generate the kernel headers and that gets include for every test-dir Makefile that includes lib.mk If the testdir in turn have its own sub-dirs the top_srcdir needs to be set to the linux-rootdir to be able to generate the kernel headers. Signed-off-by: NAnders Roxell <anders.roxell@linaro.org> Reviewed-by: NFathi Boudra <fathi.boudra@linaro.org> Signed-off-by: NShuah Khan (Samsung OSG) <shuah@kernel.org>
-
- 03 9月, 2018 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 31 8月, 2018 1 次提交
-
-
由 Stephen Rothwell 提交于
They are too noisy Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 27 8月, 2018 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 24 8月, 2018 2 次提交
-
-
由 Masahiro Yamada 提交于
Commit a0f97e06 ("kbuild: enable 'make CFLAGS=...' to add additional options to CC") renamed CFLAGS to KBUILD_CFLAGS. Commit 222d394d ("kbuild: enable 'make AFLAGS=...' to add additional options to AS") renamed AFLAGS to KBUILD_AFLAGS. Commit 06c5040c ("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: NMasahiro Yamada <yamada.masahiro@socionext.com> Acked-by: NKirill A. Shutemov <kirill.shutemov@linux.intel.com> Reviewed-by: NPalmer Dabbelt <palmer@sifive.com>
-
由 Masahiro Yamada 提交于
This config option should be enabled only when both the compiler and the linker support necessary flags. Add proper dependencies to Kconfig. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
- 22 8月, 2018 1 次提交
-
-
由 Masahiro Yamada 提交于
As commit ebaad7d3 ("kbuild: rpm: prompt to use "rpm-pkg" if "rpm" target is used") noticed, the "rpm" target is now removed. I assume people have already migrated to "rpm-pkg". Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-