- 25 6月, 2017 1 次提交
-
-
由 Matthias Kaehlcke 提交于
cc-option uses KBUILD_CFLAGS and KBUILD_CPPFLAGS when it determines whether an option is supported or not. This is fine for options used to build the kernel itself, however some components like the x86 boot code use a different set of flags. Add the new macro __cc-option which is a more generic version of cc-option with additional parameters. One parameter is the compiler with which the check should be performed, the other the compiler options to be used instead KBUILD_C*FLAGS. Refactor cc-option and hostcc-option to use __cc-option and move hostcc-option to scripts/Kbuild.include. Suggested-by: NArnd Bergmann <arnd@arndb.de> Suggested-by: NMasahiro Yamada <yamada.masahiro@socionext.com> Signed-off-by: NMatthias Kaehlcke <mka@chromium.org> Acked-by: NArnd Bergmann <arnd@arndb.de> Acked-by: NMichal Marek <mmarek@suse.com> Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
- 22 6月, 2017 1 次提交
-
-
由 Matthias Kaehlcke 提交于
clang generates plenty of these warnings in different parts of the code, to an extent that the warnings are little more than noise. Disable the 'address-of-packed-member' warning. Signed-off-by: NMatthias Kaehlcke <mka@chromium.org> Reviewed-by: NDouglas Anderson <dianders@chromium.org> Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
- 10 6月, 2017 1 次提交
-
-
由 Masahiro Yamada 提交于
Commit 90ac086b ("Makefile: include arch/*/include/generated/uapi before .../generated") introduced this for bisect'ability. The commit chose to promote arch/*/include/generated/uapi in the search path rather than cleaning stale headers. After all, we found that approach was not enough, and ended up with cleaning stale headers by commit cda2c65f ("kbuild: Remove stale asm-generic wrappers"). So, the extra search path is no longer needed because Kbuild invokes scripts/Makefile.asm-generic and remove stale headers before it starts descending. This commit is also reverting commit dc33db7c ("Kbuild: avoid duplicate include path") because we have no more duplicated path. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
- 06 6月, 2017 1 次提交
-
-
由 Masahiro Yamada 提交于
This allows to detect -s (--silent) option without checking GNU Make version. As commit e36aaea2 ("kbuild: Fix silent builds with make-4") pointed out, GNU Make 4.x changed the way/order it presents the command line options into MAKEFLAGS. In Make 3.8x, 's' is always the first in a group of short options. The group may be prefixed with '-' in some cases. In Make 4.x, 's' is always the last in a group of short options. As commit e6ac89fa ("kbuild: Correctly deal with make options which contain an 's'") addressed, we also need to deal with long options that contain 's', like --warn-undefined-variables. Test cases: [1] command line input: make --silent -> MAKEFLAGS for Make 3.8x: s -> MAKEFLAGS for Make 4.x : s [2] command line input: make -srR -> MAKEFLAGS for Make 3.8x: sRr -> MAKEFLAGS for Make 4.x : rRs [3] command line input: make -s -rR --warn-undefined-variables -> MAKEFLAGS for Make 3.8x: --warn-undefined-variables -sRr -> MAKEFLAGS for Make 4.x : rRs --warn-undefined-variables My idea to cater to all the cases more easily is to filter out long options (--%), then search 's' with $(findstring ...). This way will be more future-proof even if future versions of Make put 's' in the middle of the group. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
- 22 5月, 2017 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 18 5月, 2017 1 次提交
-
-
由 Masahiro Yamada 提交于
Since commit 61562f98 ("uapi: export all arch specifics directories"), "make INSTALL_HDR_PATH=$root/usr headers_install" deletes standard glibc headers and others in $(root)/usr/include. The cause of the issue is that headers_install now starts descending from arch/$(hdr-arch)/include/uapi with $(root)/usr/include for its destination when installing asm headers. So, headers already there are assumed to be unwanted. When headers_install starts descending from include/uapi with $(root)/usr/include for its destination, it works around the problem by creating an dummy destination $(root)/usr/include/uapi, but this is tricky. To fix the problem in a clean way is to skip headers install/check in include/uapi and arch/$(hdr-arch)/include/uapi because we know there are only sub-directories in uapi directories. A good side effect is the empty destination $(root)/usr/include/uapi will go away. I am also removing the trailing slash in the headers_check target to skip checking in arch/$(hdr-arch)/include/uapi. Fixes: 61562f98 ("uapi: export all arch specifics directories") Reported-by: NDan Williams <dan.j.williams@intel.com> Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com> Tested-by: NDan Williams <dan.j.williams@intel.com> Acked-by: NNicolas Dichtel <nicolas.dichtel@6wind.com>
-
- 14 5月, 2017 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 10 5月, 2017 1 次提交
-
-
由 Nicolas Dichtel 提交于
This patch removes the need of subdir-y. Now all files/directories under arch/<arch>/include/uapi/ are exported. The only change for userland is the layout of the command 'make headers_install_all': directories asm-<arch> are replaced by arch-<arch>/. Those new directories contains all files/directories of the specified arch. Note that only cris and tile have more directories than only asm: - arch-v[10|32] for cris; - arch for tile. Signed-off-by: NNicolas Dichtel <nicolas.dichtel@6wind.com> Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
- 09 5月, 2017 1 次提交
-
-
由 Randy Dunlap 提交于
Add a top-level Makefile help target for Userspace tools. Also make each help "heading" end with a colon ':'. Link: http://lkml.kernel.org/r/55c986ff-3966-3e47-2984-7349da2cce51@infradead.orgSigned-off-by: NRandy Dunlap <rdunlap@infradead.org> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 03 5月, 2017 1 次提交
-
-
由 Rabin Vincent 提交于
Evaluate LDFLAGS_BUILD_ID (which involves invoking the compiler) only once instead of over and over. This provides a ~20% reduction in null build time with x86 allnoconfig: $ make allnoconfig && make -j8 $ perf stat -r5 -e sched:sched_process_exec make -j8 - 2 119 sched:sched_process_exec + 1 878 sched:sched_process_exec - 1,238817018 seconds time elapsed + 0,971020553 seconds time elapsed Signed-off-by: NRabin Vincent <rabin@rab.in> Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
- 01 5月, 2017 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 28 4月, 2017 1 次提交
-
-
由 Michael Davidson 提交于
The Linux Kernel relies on GCC's acceptance of inline assembly as an opaque object which will not have any validation performed on the content. The current behaviour in LLVM is to perform validation of the contents by means of parsing the input if the MC layer can handle it. Disable clangs integrated assembler and use the GNU assembler instead. Wording-mostly-from: Saleem Abdulrasool <compnerd@compnerd.org> Signed-off-by: NMichael Davidson <md@google.com> Signed-off-by: NMatthias Kaehlcke <mka@chromium.org> Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
- 25 4月, 2017 1 次提交
-
-
由 Vinícius Tinti 提交于
Add rules to kbuild in order to generate LLVM assembly files with the .ll extension when using clang. # from c code make CC=clang kernel/pid.ll Signed-off-by: NVinícius Tinti <viniciustinti@gmail.com> Signed-off-by: NBehan Webster <behanw@converseincode.com> Signed-off-by: NMatthias Kaehlcke <mka@chromium.org> Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
- 24 4月, 2017 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 23 4月, 2017 2 次提交
-
-
由 Behan Webster 提交于
Add cross target to CC if using clang. Also add custom gcc toolchain path for fallback gcc tools. Clang will fallback to using things like ld, as, and libgcc if (respectively) one of the llvm linkers isn't available, the integrated assembler is turned off, or an appropriately cross-compiled version of compiler-rt isn't available. To this end, you can specify the path to this fallback gcc toolchain with GCC_TOOLCHAIN. Signed-off-by: NBehan Webster <behanw@converseincode.com> Reviewed-by: NJan-Simon Möller <dl9pf@gmx.de> Reviewed-by: NMark Charlebois <charlebm@gmail.com> Signed-off-by: NGreg Hackmann <ghackmann@google.com> Signed-off-by: NMatthias Kaehlcke <mka@chromium.org> Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
由 Masahiro Yamada 提交于
Since commit c3f0d0bc ("kbuild, LLVMLinux: Add -Werror to cc-option to support clang"), cc-option and friends work nicely for clang. However, -Wno-unknown-warning-option makes clang happy with any unknown warning options even if -Werror is specified. Once -Wno-unknown-warning-option is added, any succeeding call of cc-disable-warning is evaluated positive, then unknown warning options are accepted. This should be dropped. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
- 18 4月, 2017 1 次提交
-
-
由 Masahiro Yamada 提交于
Arnd Bergmann reported: "When ftrace is enabled and we build with gcc-4.7 or older, we get a warning for each file on architectures that select CONFIG_LD_DEAD_CODE_DATA_ELIMINATION: warning: -ffunction-sections disabled; it makes profiling impossible [enabled by default] " Since commit c3f0d0bc ("kbuild, LLVMLinux: Add -Werror to cc-option to support clang"), warnings are treated as errors in cc-option checks. CC_FLAGS_FTRACE is blindly added to KBUILD_CFLAGS, so $(call cc-option,-ffunction-sections,) should be moved below it in order to detect the conflict between the two options. Reported-by: NArnd Bergmann <arnd@arndb.de> Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
- 17 4月, 2017 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 13 4月, 2017 1 次提交
-
-
由 Behan Webster 提交于
This generates smaller resulting object code when compiled with clang. Signed-off-by: NBehan Webster <behanw@converseincode.com> Signed-off-by: NMatthias Kaehlcke <mka@chromium.org> Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
- 10 4月, 2017 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 03 4月, 2017 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 31 3月, 2017 1 次提交
-
-
由 Cao jin 提交于
Documentation/sparse.txt has been moved to Documentation/dev-tools/sparse.rst Signed-off-by: NCao jin <caoj.fnst@cn.fujitsu.com> Signed-off-by: NJonathan Corbet <corbet@lwn.net>
-
- 27 3月, 2017 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 22 3月, 2017 2 次提交
-
-
由 Kees Cook 提交于
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: NKees Cook <keescook@chromium.org> Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
The latest change of asm goto support check added passing of KBUILD_CFLAGS to compiler. When these flags reference gcc plugins that are not built yet, the check fails. When one runs "make bzImage" followed by "make modules", the kernel is always built with HAVE_JUMP_LABEL disabled, while the modules are built depending on CONFIG_JUMP_LABEL. If HAVE_JUMP_LABEL macro happens to be different, modules are built with undefined references, e.g.: ERROR: "static_key_slow_inc" [net/netfilter/xt_TEE.ko] undefined! ERROR: "static_key_slow_dec" [net/netfilter/xt_TEE.ko] undefined! ERROR: "static_key_slow_dec" [net/netfilter/nft_meta.ko] undefined! ERROR: "static_key_slow_inc" [net/netfilter/nft_meta.ko] undefined! ERROR: "nf_hooks_needed" [net/netfilter/ipvs/ip_vs.ko] undefined! ERROR: "nf_hooks_needed" [net/ipv6/ipv6.ko] undefined! ERROR: "static_key_count" [net/ipv6/ipv6.ko] undefined! ERROR: "static_key_slow_inc" [net/ipv6/ipv6.ko] undefined! This change moves the check before all these references are added to KBUILD_CFLAGS. This is correct because subsequent KBUILD_CFLAGS modifications are not relevant to this check. Reported-by: NAnton V. Boyarshinov <boyarsh@altlinux.org> Fixes: 35f860f9 ("jump label: pass kbuild_cflags when checking for asm goto support") Cc: stable@vger.kernel.org # v4.10 Signed-off-by: NGleb Fotengauer-Malinovskiy <glebfm@altlinux.org> Signed-off-by: NDmitry V. Levin <ldv@altlinux.org> Acked-by: NSteven Rostedt (VMware) <rostedt@goodmis.org> Acked-by: NDavid Lin <dtwlin@google.com> Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
- 20 3月, 2017 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 17 3月, 2017 1 次提交
-
-
由 Arnd Bergmann 提交于
In commit a76bcf55 ("Kbuild: enable -Wmaybe-uninitialized warning for "make W=1""), I reverted another change that happened to fix a problem with old compilers, and now we get this report again with old compilers (prior to gcc-4.8) and GCOV enabled: cc1: warnings being treated as errors drivers/gpu/drm/i915/intel_ringbuffer.c: In function 'intel_ring_setup_status_page': drivers/gpu/drm/i915/intel_ringbuffer.c:438: error: 'mmio.reg' may be used uninitialized in this function At top level: >> cc1: error: unrecognized command line option "-Wno-maybe-uninitialized" The problem is that we turn off the warning conditionally in a number of places as we should, but one of them does it unconditionally. Instead, change it to call cc-disable-warning as we do elsewhere. The original patch that caused it was merged into linux-4.7, then 4.8 removed the change and 4.9 brought it back, so we probably want a backport to 4.9 once this is merged. Use a ':=' assignment instead of '=' to force the cc-disable-warning call to only be evaluated once instead of every time. Cc: stable@vger.kernel.org Fixes: a76bcf55 ("Kbuild: enable -Wmaybe-uninitialized warning for "make W=1"") Fixes: e72e2dfe ("gcov: disable -Wmaybe-uninitialized warning") Reported-by: Nkbuild test robot <fengguang.wu@intel.com> Signed-off-by: NArnd Bergmann <arnd@arndb.de> Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
- 15 3月, 2017 1 次提交
-
-
由 Masahiro Yamada 提交于
The patterns '.*.orig' and '.*.rej' are cleaned away by '*.orig' and '*.rej' seen two lines above. Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
- 13 3月, 2017 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 11 3月, 2017 1 次提交
-
-
由 Seung-Woo Kim 提交于
Extra gcc checks like W=1 were moved to scripts/Makefile.exrawarn, so the file name in comment needs to be fixed. Signed-off-by: NSeung-Woo Kim <sw0312.kim@samsung.com> Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
-
- 06 3月, 2017 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 20 2月, 2017 2 次提交
-
-
由 Josh Poimboeuf 提交于
When building a CONFIG_STACK_VALIDATION enabled kernel without the libelf devel package installed, the Makefile prints a warning: "Cannot use CONFIG_STACK_VALIDATION, please install libelf-dev, libelf-devel or elfutils-libelf-devel" But when building an out-of-tree module, the warning doesn't show. Instead it tries to use objtool, and the build fails with: /bin/sh: ./tools/objtool/objtool: No such file or directory Make sure the warning and the disabling of objtool occur in all cases, by moving the CONFIG_STACK_VALIDATION checks outside the 'ifeq ($(KBUILD_EXTMOD),)' block in the Makefile. Tested-By: NMarc MERLIN <marc@merlins.org> Suggested-by: NJessica Yu <jeyu@redhat.com> Reported-by: NMarc MERLIN <marc@merlins.org> Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com> Reviewed-by: NJessica Yu <jeyu@redhat.com> Cc: Linus Torvalds <torvalds@linux-foundation.org> Cc: Michal Marek <mmarek@suse.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Thomas Gleixner <tglx@linutronix.de> Fixes: 3b27a0c8 ("objtool: Detect and warn if libelf is missing and don't break the build") Link: http://lkml.kernel.org/r/b3088ae4a8698143d4851965793c61fec2135b1f.1487182864.git.jpoimboe@redhat.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
-
由 Linus Torvalds 提交于
-
- 16 2月, 2017 1 次提交
-
-
由 Rémy Léone 提交于
Documentation shouldn't have broken links. sphinx linkcheck builder scans all documents for external links, tries to open them with urllib2, and writes an overview which ones are broken and redirected to standard output and to output.txt in the output directory. Reviewed-by: NJani Nikula <jani.nikula@intel.com> Tested-by: NJani Nikula <jani.nikula@intel.com> Signed-off-by: NRémy Léone <remy.leone@gmail.com> Signed-off-by: NJonathan Corbet <corbet@lwn.net>
-
- 13 2月, 2017 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 06 2月, 2017 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 04 2月, 2017 1 次提交
-
-
由 David Lin 提交于
Some versions of ARM GCC compiler such as Android toolchain throws in a '-fpic' flag by default. This causes the gcc-goto check script to fail although some config would have '-fno-pic' flag in the KBUILD_CFLAGS. This patch passes the KBUILD_CFLAGS to the check script so that the script does not rely on the default config from different compilers. Link: http://lkml.kernel.org/r/20170120234329.78868-1-dtwlin@google.comSigned-off-by: NDavid Lin <dtwlin@google.com> Acked-by: NSteven Rostedt <rostedt@goodmis.org> Cc: Michal Marek <mmarek@suse.com> Signed-off-by: NAndrew Morton <akpm@linux-foundation.org> Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
-
- 30 1月, 2017 1 次提交
-
-
由 Linus Torvalds 提交于
-
- 27 1月, 2017 1 次提交
-
-
由 Josh Poimboeuf 提交于
When doing a kernel build with 'make -s', everything is silenced except the objtool build. That's because the tools tree support for silent builds is some combination of missing and broken. Three changes are needed to fix it: - Makefile: propagate '-s' to the sub-make's MAKEFLAGS variable so the tools Makefiles can see it. - tools/scripts/Makefile.include: fix the tools Makefiles' ability to recognize '-s'. The MAKE_VERSION and MAKEFLAGS checks are copied from the top-level Makefile. This silences the "DESCEND objtool" message. - tools/build/Makefile.build: add support to the tools Build files for recognizing '-s'. Again the MAKE_VERSION and MAKEFLAGS checks are copied from the top-level Makefile. This silences all the object compile/link messages. Reported-and-Tested-by: NPeter Zijlstra <peterz@infradead.org> Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Michal Marek <mmarek@suse.com> Link: http://lkml.kernel.org/r/e8967562ef640c3ae9a76da4ae0f4e47df737c34.1484799200.git.jpoimboe@redhat.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
-
- 23 1月, 2017 1 次提交
-
-
由 Linus Torvalds 提交于
-