- 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 提交于
-
- 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>
-
- 21 8月, 2018 1 次提交
-
-
由 Andy Lutomirski 提交于
Currently, if the vDSO ends up containing an indirect branch or call, GCC will emit the "external thunk" style of retpoline, and it will fail to link. Fix it by building the vDSO with inline retpoline thunks. I haven't seen any reports of this triggering on an unpatched kernel. Fixes: commit 76b04384 ("x86/retpoline: Add initial retpoline support") Signed-off-by: NAndy Lutomirski <luto@kernel.org> Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Acked-by: NMatt Rickard <matt@softrans.com.au> Cc: Borislav Petkov <bp@alien8.de> Cc: Jason Vas Dias <jason.vas.dias@gmail.com> Cc: David Woodhouse <dwmw2@infradead.org> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Andi Kleen <ak@linux.intel.com> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/c76538cd3afbe19c6246c2d1715bc6a60bd63985.1534448381.git.luto@kernel.org
-
- 16 8月, 2018 3 次提交
-
-
由 Vasily Gorbik 提交于
-mcount-nop gcc option generates the calls to the profiling functions as nops which allows to avoid patching mcount jump with NOP instructions initially. -mcount-nop gcc option will be activated if platform selects HAVE_NOP_MCOUNT and gcc actually supports it. In addition to that CC_USING_NOP_MCOUNT is defined and could be used by architectures to adapt ftrace patching behavior. Link: http://lkml.kernel.org/r/patch-3.thread-aa7b8d.git-e02ed2dc082b.your-ad-here.call-01533557518-ext-9465@work.hoursSigned-off-by: NVasily Gorbik <gor@linux.ibm.com> Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
-
由 Vasily Gorbik 提交于
Currently if CONFIG_FTRACE_MCOUNT_RECORD is enabled -mrecord-mcount compiler flag support is tested for every Makefile. Top 4 cc-option usages: 511 -mrecord-mcount 11 -fno-stack-protector 9 -Wno-override-init 2 -fsched-pressure To address that move cc-option from scripts/Makefile.build to top Makefile and export CC_USING_RECORD_MCOUNT to be used in original place. While doing that also add -mrecord-mcount to CC_FLAGS_FTRACE (if gcc actually supports it). Link: http://lkml.kernel.org/r/patch-2.thread-aa7b8d.git-de935bace15a.your-ad-here.call-01533557518-ext-9465@work.hoursAcked-by: NAndi Kleen <ak@linux.intel.com> Signed-off-by: NVasily Gorbik <gor@linux.ibm.com> Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
-
由 Vasily Gorbik 提交于
CC_FLAGS_FTRACE is exported and later used to remove ftrace relevant build flags from files which should be built without ftrace support. For that reason add -mfentry to CC_FLAGS_FTRACE as well. That fixes a problem with vdso32 build on s390, where -mfentry could not be used together with -m31 flag. At the same time flags like -pg and -mfentry are not relevant for asm files, so avoid adding them to KBUILD_AFLAGS. Introduce CC_FLAGS_USING instead of CC_USING_FENTRY to collect -DCC_USING_FENTRY (and future alike) which are relevant for both KBUILD_CFLAGS and KBUILD_AFLAGS. Link: http://lkml.kernel.org/r/patch-1.thread-aa7b8d.git-42971afe87de.your-ad-here.call-01533557518-ext-9465@work.hoursSigned-off-by: NVasily Gorbik <gor@linux.ibm.com> Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
-
- 13 8月, 2018 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 09 8月, 2018 1 次提交
-
-
由 Masahiro Yamada 提交于
Kernel headers must be installed into $(objtree)/usr/include to avoid the build failure of samples. Commit ddea05fa ("kbuild: make samples depend on headers_install") addressed this, but "samples/" is only used for the single target build. "make samples/" properly installs kernel headers, but it does not work for general building because a phony target "sample" (no trailing slash) is used. Reported-by: NDavid Howells <dhowells@redhat.com> Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com> Tested-by: NDavid Howells <dhowells@redhat.com>
-
- 07 8月, 2018 1 次提交
-
-
由 Masahiro Yamada 提交于
asm-generic and uapi-asm-generic do not depend on the kernel configuration. In fact, uapi-asm-generic is the prerequisite of headers_{install,check}, hence it should not require the .config file. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com> Tested-by: NRandy Dunlap <rdunlap@infradead.org> Acked-by: NRichard Weinberger <richard@nod.at>
-
- 06 8月, 2018 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 30 7月, 2018 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 28 7月, 2018 1 次提交
-
-
由 Masahiro Yamada 提交于
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: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
- 25 7月, 2018 4 次提交
-
-
由 Masahiro Yamada 提交于
The top-level Makefile adds include/config/auto.conf as prerequisites of 'scripts', 'prepare1', etc. They were needed to terminate the build when include/config/auto.conf is missing. Now that the inclusion of include/config/auto.conf is mandatory in the top-level Makefile if dot-config is 1 (Note 'include' directive is used instead of '-include'). Make terminates the build by itself if it fails to create or update include/config/auto.conf so we are sure that include/config/auto.conf exists in the very first stage of make. I am still keeping include/config/auto.conf as the prerequisite of %/modules.builtin because modules.builtin is a real file. According to commit a6c36632 ("kbuild: Do not unnecessarily regenerate modules.builtin"), it is intentional to compare time-stamps between %/modules.builtin and include/config/auto.conf . I moved tristate.conf here because it is only included from scripts/Makefile.modbuiltin. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
由 Masahiro Yamada 提交于
'make kernelrelease' depends on CONFIG_LOCALVERSION(_AUTO), but for the same reason as install targets, we do not want to update the configuration just for printing the kernelrelease string. This is likely to happen when you compiled the kernel with CROSS_COMPILE, but forget to pass it to 'make kernelrelease'. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
由 Masahiro Yamada 提交于
"make syncconfig" is automatically invoked when any of the following happens: - .config is updated - any of Kconfig files is updated - any of environment variables referenced in Kconfig is changed Then, it updates configuration files such as include/config/auto.conf include/generated/autoconf.h, etc. Even install targets (install, modules_install, etc.) are no exception. However, they should never ever modify the source tree. Install targets are often run with root privileges. Once those configuration files are owned by root, "make mrproper" would end up with permission error. Install targets should just copy things blindly. They should not care whether the configuration is up-to-date or not. This makes more sense because we are interested in the configuration that was used in the previous kernel building. This issue has existed since before, but rarely happened. I expect more chance where people are hit by this; with the new Kconfig syntax extension, the .config now contains the compiler information. If you cross-compile the kernel with CROSS_COMPILE, but forget to pass it for "make install", you meet "any of environment variables referenced in Kconfig is changed" because $(CC) is referenced in Kconfig. Another scenario is the compiler upgrade before the installation. Install targets need the configuration. "make modules_install" refer to CONFIG_MODULES etc. "make dtbs_install" also needs CONFIG_ARCH_* to decide which dtb files to install. However, the auto-update of the configuration files should be avoided. We already do this for external modules. Now, Make targets are categorized into 3 groups: [1] Do not need the kernel configuration at all help, coccicheck, headers_install etc. [2] Need the latest kernel configuration If new config options are added, Kconfig will show prompt to ask user's selection. Build targets such as vmlinux, in-kernel modules are the cases. [3] Need the kernel configuration, but do not want to update it Install targets except headers_install, and external modules are the cases. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
由 Masahiro Yamada 提交于
When you build targets that require the kernel configuration, dot-config is set to 1, then the top-level Makefile includes auto.conf. However, Make considers its inclusion is optional because the '-include' directive is used here. If a necessary configuration file is missing for the external module building, the following error message is displayed: ERROR: Kernel configuration is invalid. include/generated/autoconf.h or include/config/auto.conf are missing. Run 'make oldconfig && make prepare' on kernel src to fix it. However, Make still continues building; /bin/false let the creation of 'include/config/auto.config' fail, but Make can ignore the error since it is included by the '-include' directive. I guess the reason of using '-include' directive was to suppress the warning when you build the kernel from a pristine source tree: Makefile:605: include/config/auto.conf: No such file or directory The previous commit made sure include/config/auto.conf exists after the 'make *config' stage. Now, we can use the 'include' directive without showing the warning. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-