Original comments is confusing on "OBJ directory", make it clear.
Bonus: move comments close to what it wants to comment.
Signed-off-by: NCao jin <caoj.fnst@cn.fujitsu.com>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

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>

There were a few bits and pieces left over from the now-disused DocBook
toolchain; git rid of them.
Reported-by: NMarkus Heiser <markus.heiser@darmarit.de>
Signed-off-by: NJonathan Corbet <corbet@lwn.net>

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>

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>

The help info of `make C=1` is little confusing, make it clear.
Signed-off-by: NCao jin <caoj.fnst@cn.fujitsu.com>
Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>

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>

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>

Now that we don't have any DocBook anymore, remove it from
the building system.
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>

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>