- 29 4月, 2019 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 22 4月, 2019 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 15 4月, 2019 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 08 4月, 2019 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 01 4月, 2019 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 28 3月, 2019 3 次提交
-
-
由 Masahiro Yamada 提交于
Commit 3a51ff34 ("kbuild: gitignore output directory") seemed to bother people who version-control output directories. Andre Przywara says: "Unfortunately this breaks my setup, because I keep a totally separate git repository in my build directories to track (various versions of) .config. So .gitignore there is carefully crafted to ignore most build artefacts, but not .config, for instance." Link: https://lkml.org/lkml/2019/3/22/1819Reported-by: NAndre Przywara <andre.przywara@arm.com> Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com> Tested-by: NAndre Przywara <andre.przywara@arm.com> Reviewed-by: NAndre Przywara <andre.przywara@arm.com>
-
由 Masahiro Yamada 提交于
When Make recurses to the top Makefile with sub-make-done unset, the code block surrounded by 'ifneq ($(sub-make-done),1) ... endif' is parsed multiple times. This happens for in-tree building of include/config/auto.conf, *-pkg, etc. with GNU Make 4.x. This is a slight regression by commit 688931a5 ("kbuild: skip sub-make for in-tree build with GNU Make 4.x") in terms of performance since that code block contains one $(shell ...) invocation. Fix it by exporting the variable irrespective of sub-make being run. I renamed it because GNU Make cannot properly export variables containing hyphens. This is probably a bug of GNU Make, and the issue in Kbuild had already been reported by commit 2bfbe788 ("kbuild: Do not use hyphen in exported variable name"). Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
由 Rolf Eike Beer 提交于
If it is not in the default location, compilation fails at several points. Signed-off-by: NRolf Eike Beer <eb@emlix.com> Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com> Signed-off-by: NThomas Gleixner <tglx@linutronix.de> Cc: stable@vger.kernel.org Link: https://lkml.kernel.org/r/91a25e992566a7968fedc89ec80e7f4c83ad0548.1553622500.git.jpoimboe@redhat.com
-
- 25 3月, 2019 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 21 3月, 2019 1 次提交
-
-
由 Masahiro Yamada 提交于
Commit 2b50f7ab ("kbuild: add workaround for Debian make-kpkg") annoyed people who want to wrap the top Makefile with GNUmakefile to customize it for their use. On second thought, we do not need to run the sub-make for in-tree build with Make 4.x because the 'MAKEFLAGS += -rR' issue only happens on GNU Make 3.x. With this commit, people will get back their workflow, and the Debian make-kpkg will still work. Fixes: 2b50f7ab ("kbuild: add workaround for Debian make-kpkg") Reported-by: NAndreas Schwab <schwab@suse.de> Reported-by: NDavid Howells <dhowells@redhat.com> Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com> Tested-by: NAndreas Schwab <schwab@suse.de> Tested-by: NDavid Howells <dhowells@redhat.com>
-
- 20 3月, 2019 1 次提交
-
-
由 Matthias Kaehlcke 提交于
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 6748cb3c. Suggested-by: NPeter Zijlstra <peterz@infradead.org> Signed-off-by: NMatthias Kaehlcke <mka@chromium.org> Reviewed-by: NNick Desaulniers <ndesaulniers@google.com> Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
- 18 3月, 2019 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 17 3月, 2019 2 次提交
-
-
由 Masahiro Yamada 提交于
Currently, every arch/*/include/uapi/asm/Kbuild explicitly includes the common Kbuild.asm file. Factor out the duplicated include directives to scripts/Makefile.asm-generic so that no architecture would opt out of the mandatory-y mechanism. um is not forced to include mandatory-y since it is a very exceptional case which does not support UAPI. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
由 Douglas Anderson 提交于
During a simple no-op (nothing changed) build I saw 39 invocations of the C compiler with the argument "-print-file-name=include". We don't need to call the C compiler 39 times for this--one time will suffice. Let's change NOSTDINC_FLAGS to a simply expanded variable to avoid this since there doesn't appear to be any reason it should be recursively expanded. On my build this shaved ~400 ms off my "no-op" build. Note that the recursive expansion seems to date back to the (really old) commit e8f5bdb0 ("[PATCH] Makefile include path ordering"). It's a little unclear to me if the point of that patch was to switch the variable to be recursively expanded (which it did) or to avoid directly assigning to NOSTDINC_FLAGS (AKA to switch to +=) because someone else (out of tree?) was setting it. I presume later since if the only goal was to switch to recursive expansion the patch would have just removed the ":". Signed-off-by: NDouglas Anderson <dianders@chromium.org> Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
- 14 3月, 2019 1 次提交
-
-
由 Masahiro Yamada 提交于
Since commit 3812b8c5 ("kbuild: make -r/-R effective in top Makefile for old Make versions"), make-kpkg is not working. make-kpkg directly includes the top Makefile of Linux kernel, and appends some debian_* targets. /usr/share/kernel-package/ruleset/kernel_version.mk: # Include the kernel makefile override dot-config := 1 include Makefile dot-config := 1 I did not know the kernel Makefile was used in that way, and it is hard to guarantee the behavior when the kernel Makefile is included by another Makefile from a different project. It looks like Debian Stretch stopped providing make-kpkg. Maybe it is obsolete and being replaced with 'make deb-pkg' etc. but still widely used. This commit adds a workaround; if the top Makefile is included by another Makefile, skip sub-make in order to make the main part visible. 'MAKEFLAGS += -rR' does not become effective for GNU Make < 4.0, but Debian/Ubuntu is already using newer versions. The effect of this commit: Debian 8 (Jessie) : Fixed Debian 9 (Stretch) : make-kpkg (kernel-package) is not provided Ubuntu 14.04 LTS : NOT Fixed Ubuntu 16.04 LTS : Fixed Ubuntu 18.04 LTS : Fixed This commit cannot fix Ubuntu 14.04 because it installs GNU Make 3.81, but its support will end in Apr 2019, which is before the Linux v5.1 release. I added warning so that nobody would try to include the top Makefile. Fixes: 3812b8c5 ("kbuild: make -r/-R effective in top Makefile for old Make versions") Reported-by: NLiz Zhang <lizzha@microsoft.com> Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com> Tested-by: NLili Deng <v-lide@microsoft.com> Cc: Manoj Srivastava <srivasta@debian.org>
-
- 05 3月, 2019 1 次提交
-
-
由 Masahiro Yamada 提交于
This build rule was introduced by commit cd05e6bd ("[PATCH] kbuild: fix split-include dependency") to handle the dependency of scripts/basic/split-include. Now, fixdep is the only tool in scripts/basic/, and this rule is no longer used. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
- 04 3月, 2019 3 次提交
-
-
由 Luc Van Oostenryck 提交于
The flag '-Werror-implicit-function-declaration', present in GCC 2.95, stopped to be documented in GCC 4.3, replaced by the more generic '-Werror=...' form. So, use the equivalent '-Werror=implicit-function-declaration' instead. Signed-off-by: NLuc Van Oostenryck <luc.vanoostenryck@gmail.com> Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
由 Masahiro Yamada 提交于
This code has been commented out since commit b7000ade ("Don't set the INITRD_COMPRESS environment variable automatically"). Clean it up now. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
由 Linus Torvalds 提交于
-
- 28 2月, 2019 1 次提交
-
-
由 Masahiro Yamada 提交于
CONFIG_DEBUG_INFO_SPLIT and CONFIG_DEBUG_INFO_DWARF4 enable extra dwarf options if supported. You never know if they are really enabled since Makefile may silently turn them off. The actual behavior will match to the kernel configuration by testing those compiler flags in the Kconfig stage. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
- 27 2月, 2019 11 次提交
-
-
由 Masahiro Yamada 提交于
If you run "make" in a pristine source tree, currently Kbuild will start to build Kconfig to let it show the error message. It would be more straightforward to check it in Makefile and let it fail immediately. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
由 Masahiro Yamada 提交于
If include/config/auto.conf.cmd is lost for some reasons, it is not self-healing, so the top Makefile misses to run syncconfig. Move include/config/auto.conf.cmd to the target side. I used a pattern rule instead of a normal rule here although it is a bit gross. If the rule were written with a normal rule like this, include/config/auto.conf \ include/config/auto.conf.cmd \ include/config/tristate.conf: $(KCONFIG_CONFIG) $(Q)$(MAKE) -f $(srctree)/Makefile syncconfig ... syncconfig would be executed per target. Using a pattern rule makes sure that syncconfig is executed just once because Make assumes the recipe will create all of the targets. Here is a quote from the GNU Make manual [1]: "Pattern rules may have more than one target. Unlike normal rules, this does not act as many different rules with the same prerequisites and recipe. If a pattern rule has multiple targets, make knows that the rule's recipe is responsible for making all of the targets. The recipe is executed only once to make all the targets. When searching for a pattern rule to match a target, the target patterns of a rule other than the one that matches the target in need of a rule are incidental: make worries only about giving a recipe and prerequisites to the file presently in question. However, when this file's recipe is run, the other targets are marked as having been updated themselves." [1]: https://www.gnu.org/software/make/manual/html_node/Pattern-Intro.htmlSigned-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
由 Masahiro Yamada 提交于
The dependency will be checked anyway after Kbuild descends into a sub-directory. Skip object/source dependency checks in top Makefile. VPATH can be simpler since the top Makefile no longer checks the presence of the source file, which is located in in the external module directory. One good thing is, it can compile an object from a generated source file. $ make crypto/rsapubkey.asn1.o ... ASN.1 crypto/rsapubkey.asn1.c CC crypto/rsapubkey.asn1.o Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
由 Masahiro Yamada 提交于
The previous commit made 'MAKEFLAGS += -rR' effective in the top Makefile regardless of O= option, GNU Make versions. The top Makefile does not need to cancel implicit rules for makefiles. There is still one place where an empty rule is useful. Since -rR is effective only after sub-make, GNU Make would try implicit rules to update the top Makefile. Although it is not a big overhead, cancel it just in case. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
由 Masahiro Yamada 提交于
Adding -rR to MAKEFLAGS is important because we do not want to be bothered by built-in implicit rules or variables. One problem that used to exist in older GNU Make versions is MAKEFLAGS += -rR ... does not become effective in the current Makefile. When you are building with O= option, it becomes effective in the top Makefile since it recurses via 'sub-make' target. Otherwise, the top Makefile tries implicit rules. That is why we explicitly add empty rules for Makefiles, but we often miss to do that. In fact, adding -d option to older GNU Make versions shows it is trying a bunch of implicit pattern rules. Considering target file `scripts/Makefile.kcov'. Looking for an implicit rule for `scripts/Makefile.kcov'. Trying pattern rule with stem `Makefile.kcov'. Trying implicit prerequisite `scripts/Makefile.kcov.o'. Trying pattern rule with stem `Makefile.kcov'. Trying implicit prerequisite `scripts/Makefile.kcov.c'. Trying pattern rule with stem `Makefile.kcov'. Trying implicit prerequisite `scripts/Makefile.kcov.cc'. Trying pattern rule with stem `Makefile.kcov'. Trying implicit prerequisite `scripts/Makefile.kcov.C'. ... This issue was fixed by GNU Make commit 58dae243526b ("[Savannah #20501] Handle adding -r/-R to MAKEFLAGS in the makefile"). So, it is no longer a problem if you use GNU Make 4.0 or later. However, older versions are still widely used. So, I decided to patch the kernel Makefile to invoke sub-make regardless of O= option. This will allow further cleanups. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
由 Masahiro Yamada 提交于
This would disturb the change the sub-make part. Move it near the tools/ target. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
由 Masahiro Yamada 提交于
Since -Wmaybe-uninitialized was introduced by GCC 4.7, we have patched various false positives: - commit e74fc973 ("Turn off -Wmaybe-uninitialized when building with -Os") turned off this option for -Os. - commit 815eb71e ("Kbuild: disable 'maybe-uninitialized' warning for CONFIG_PROFILE_ALL_BRANCHES") turned off this option for CONFIG_PROFILE_ALL_BRANCHES - commit a76bcf55 ("Kbuild: enable -Wmaybe-uninitialized warning for "make W=1"") turned off this option for GCC < 4.9 Arnd provided more explanation in https://lkml.org/lkml/2017/3/14/903 I think this looks better by shifting the logic from Makefile to Kconfig. Link: https://github.com/ClangBuiltLinux/linux/issues/350Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: NNathan Chancellor <natechancellor@gmail.com> Tested-by: NNick Desaulniers <ndesaulniers@google.com>
-
由 Masahiro Yamada 提交于
The genksyms source was integrated into the kernel tree in 2003. I do not expect anybody still using the external /sbin/genksyms. Kbuild does not need to provide the ability to override GENKSYMS. Let's remove the GENKSYMS variable, and use the hardcoded path. Since it occurred in the pre-git era, I attached the commit message in case somebody is interested in the historical background. | Author: Kai Germaschewski <kai@tp1.ruhr-uni-bochum.de> | Date: Wed Feb 19 04:17:28 2003 -0600 | | kbuild: [PATCH] put genksyms in scripts dir | | This puts genksyms into scripts/genksyms/. | | genksyms used to be maintained externally, though the only possible user | was the kernel build. Moving it into the kernel sources makes it easier to | keep it uptodate, like for example updating it to generate linker scripts | directly instead of postprocessing the generated header file fragments | with sed, as we do currently. | | Also, genksyms does not handle __typeof__, which needs to be fixed since | some of the exported symbol in the kernel are defined using __typeof__. | | (Rusty Russell/me) Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
由 Masahiro Yamada 提交于
It is weird to create gdb stuff as a side-effect of vmlinux. Move it to a more relevant place. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: NKieran Bingham <kieran.bingham@ideasonboard.com>
-
由 Masahiro Yamada 提交于
Currently, Kbuild descends from scripts/Makefile to scripts/gdb/Makefile just for creating symbolic links, but it does not need to do it so early. Merge the two descending paths to simplify the code. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: NKieran Bingham <kieran.bingham@ideasonboard.com>
-
由 Masahiro Yamada 提交于
scripts/gdb/linux/constants.py is never used in the kernel build process. There is no good reason to create it so early. Get it out of the 'prepare' stage. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com> Reviewed-by: NKieran Bingham <kieran.bingham@ideasonboard.com>
-
- 25 2月, 2019 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 20 2月, 2019 4 次提交
-
-
由 Masahiro Yamada 提交于
Commit 06300b21 ("kbuild: support building individual files for external modules") introduced the '/' target. It works only for external modules to build all .o files, but skip the modpost stage. However, 'make /' looks a bit weird to me. 'make ./' is more sensible if you want to build all objects under the current directory, and it works as expected. Let's change '/' into a phony target that is an alias of './', but I may feel like deprecating it in the future. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
由 Masahiro Yamada 提交于
It is fine to set KBUILD_MODULES=1 when CONFIG_MODULES is disabled. It is actually how "make allnoconfig all" works. On the other hand, KBUILD_MODULES=1 is unneeded for the %.ko pattern. It is just a matter of whether modules.order is generated or not. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
由 Nick Desaulniers 提交于
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: 785f11aa ("kbuild: Add better clang cross build support") Link: https://github.com/ClangBuiltLinux/linux/issues/341Suggested-by: NNathan Chancellor <natechancellor@gmail.com> Reviewed-by: NNathan Chancellor <natechancellor@gmail.com> Tested-by: NNathan Chancellor <natechancellor@gmail.com> Signed-off-by: NNick Desaulniers <ndesaulniers@google.com> Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
由 Masahiro Yamada 提交于
Modern gcc adds view assignments, reset assertion checking in .loc directives and a couple more additional debug markers, which clutters the asm output unnecessarily: For example: bsp_resume: .LFB3466: .loc 1 1868 1 is_stmt 1 view -0 .cfi_startproc .loc 1 1869 2 view .LVU73 # arch/x86/kernel/cpu/common.c:1869: if (this_cpu->c_bsp_resume) .loc 1 1869 14 is_stmt 0 view .LVU74 movq this_cpu(%rip), %rax # this_cpu, this_cpu movq 64(%rax), %rax # this_cpu.94_1->c_bsp_resume, _2 # arch/x86/kernel/cpu/common.c:1869: if (this_cpu->c_bsp_resume) .loc 1 1869 5 view .LVU75 testq %rax, %rax # _2 je .L8 #, .loc 1 1870 3 is_stmt 1 view .LVU76 movq $boot_cpu_data, %rdi #, jmp __x86_indirect_thunk_rax or .loc 2 57 9 view .LVU478 .loc 2 57 9 view .LVU479 .loc 2 57 9 view .LVU480 .loc 2 57 9 view .LVU481 .LBB1385: .LBB1383: .LBB1379: .LBB1377: .LBB1375: .loc 2 57 9 view .LVU482 .loc 2 57 9 view .LVU483 movl %edi, %edx # cpu, cpu .LVL87: .loc 2 57 9 is_stmt 0 view .LVU484 That MOV in there is drowned in debugging information and latter makes it hard to follow the asm. And that DWARF info is not really needed for asm output staring. Disable the debug information generation which clutters the asm output unnecessarily: bsp_resume: # arch/x86/kernel/cpu/common.c:1869: if (this_cpu->c_bsp_resume) movq this_cpu(%rip), %rax # this_cpu, this_cpu movq 64(%rax), %rax # this_cpu.94_1->c_bsp_resume, _2 # arch/x86/kernel/cpu/common.c:1869: if (this_cpu->c_bsp_resume) testq %rax, %rax # _2 je .L8 #, # arch/x86/kernel/cpu/common.c:1870: this_cpu->c_bsp_resume(&boot_cpu_data); movq $boot_cpu_data, %rdi #, jmp __x86_indirect_thunk_rax .L8: # arch/x86/kernel/cpu/common.c:1871: } rep ret .size bsp_resume, .-bsp_resume [ bp: write commit message. ] Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: NBorislav Petkov <bp@suse.de>
-
- 19 2月, 2019 1 次提交
-
-
由 Vladimir Kondratiev 提交于
When compiling into output directory using O=, many files created under KBUILD_OUTPUT that git considers as new ones; git clients, ex. "git gui" lists it, and it clutters file list making it difficult to see what was really changed Generate .gitignore in output directory that ignores all its content Signed-off-by: NVladimir Kondratiev <vladimir.kondratiev@linux.intel.com> Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
- 18 2月, 2019 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 11 2月, 2019 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 04 2月, 2019 1 次提交
-
-
由 Linus Torvalds 提交于
-