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: Masahiro Yamada <yamada.masahiro@socionext.com>

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: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

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: Liz Zhang <lizzha@microsoft.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Tested-by: Lili Deng <v-lide@microsoft.com>
Cc: Manoj Srivastava <srivasta@debian.org>

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: Masahiro Yamada <yamada.masahiro@socionext.com>

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: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

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: Masahiro Yamada <yamada.masahiro@socionext.com>

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: Masahiro Yamada <yamada.masahiro@socionext.com>

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: Masahiro Yamada <yamada.masahiro@socionext.com>

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.html



Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

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: Masahiro Yamada <yamada.masahiro@socionext.com>

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: Masahiro Yamada <yamada.masahiro@socionext.com>

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: Masahiro Yamada <yamada.masahiro@socionext.com>

This would disturb the change the sub-make part. Move it near the
tools/ target.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

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/350


Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Tested-by: Nick Desaulniers <ndesaulniers@google.com>

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: Masahiro Yamada <yamada.masahiro@socionext.com>

It is weird to create gdb stuff as a side-effect of vmlinux.

Move it to a more relevant place.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>

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: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>

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: Masahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: Kieran Bingham <kieran.bingham@ideasonboard.com>

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: Masahiro Yamada <yamada.masahiro@socionext.com>

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: Masahiro Yamada <yamada.masahiro@socionext.com>

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/341


Suggested-by: Nathan Chancellor <natechancellor@gmail.com>
Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
Tested-by: Nathan Chancellor <natechancellor@gmail.com>
Signed-off-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

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: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Borislav Petkov <bp@suse.de>

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: Vladimir Kondratiev <vladimir.kondratiev@linux.intel.com>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

There is no build order among the following:
  prepare3
  outputmakefile
  asm-generic
  $(version_h)
  $(autoksyms_h)
  include/generated/utsrelease.h

It is meaningless to insert the prepare2 target between the first
three and the last three.

The comment says, "prepare2 creates a makefile if using a separate
output directory." Let me explain it more precisely. The prepare
targets cannot be executed without the .config file. Because the
configuration targets depend on the outputmakefile target, the
generated makefile is already there before the parepare2 is run.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

The top Makefile does not need to export KBUILD_VMLINUX_INIT and
KBUILD_VMLINUX_MAIN separately.

Put every built-in.a into KBUILD_VMLINUX_OBJS. The order of
$(head-y), $(init-y), $(core-y), ... is still retained.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Currently, the 'firmware' directory only contains a single Makefile
to embed extra firmware into the kernel.

Move it to the more relevant place.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>

Commit c3ff2a51 ("powerpc/32: add stack protector support")
caused kernel panic on PowerPC when an external module is used with
CONFIG_STACKPROTECTOR because the 'prepare' target was not executed
for the external module build.

Commit e07db28e ("kbuild: fix single target build for external
module") turned it into a build error because the 'prepare' target is
now executed but the 'prepare0' target is missing for the external
module build.

External module on arm/arm64 with CONFIG_STACKPROTECTOR_PER_TASK is
also broken in the same way.

Move 'PHONY += prepare0' to the common place. GNU Make is fine with
missing rule for phony targets. I also removed the comment which is
wrong irrespective of this commit.

I minimize the change so it can be easily backported to 4.20.x

To fix v4.20, please backport e07db28e ("kbuild: fix single target
build for external module"), and then this commit.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=201891


Fixes: e07db28e ("kbuild: fix single target build for external module")
Fixes: c3ff2a51 ("powerpc/32: add stack protector support")
Fixes: 189af465 ("ARM: smp: add support for per-task stack canaries")
Fixes: 0a1213fa ("arm64: enable per-task stack canaries")
Cc: linux-stable <stable@vger.kernel.org> # v4.20
Reported-by: Samuel Holland <samuel@sholland.org>
Reported-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Alexey Kardashevskiy <aik@ozlabs.ru>

No one uses archmrproper.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Make simply skips a missing rule when it is marked as .PHONY.
Remove the dummy targets.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>