Skip to content

L
linux
An error occurred fetching the project authors.
Switch branch/tag
  1. 27 Feb, 2019 7 commits
  3. 20 Feb, 2019 4 commits
    • Masahiro Yamada's avatar
      kbuild: turn '/' into an alias of './' · 6d3c94e4
      Masahiro Yamada authored 
      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: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      6d3c94e4
    • Masahiro Yamada's avatar
      kbuild: set KBUILD_MODULES=1 all the time for single target %/ · 648ad9b1
      Masahiro Yamada authored 
      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: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      648ad9b1
    • Nick Desaulniers's avatar
      kbuild: clang: choose GCC_TOOLCHAIN_DIR not on LD · ad15006c
      Nick Desaulniers authored 
      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: default avatarNathan Chancellor <natechancellor@gmail.com>
Reviewed-by: default avatarNathan Chancellor <natechancellor@gmail.com>
Tested-by: default avatarNathan Chancellor <natechancellor@gmail.com>
Signed-off-by: default avatarNick Desaulniers <ndesaulniers@google.com>
Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      ad15006c
    • Masahiro Yamada's avatar
      kbuild: Disable extra debugging info in .s output · 1e88e415
      Masahiro Yamada authored 
      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: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
Signed-off-by: default avatarBorislav Petkov <bp@suse.de>
      1e88e415
  5. 19 Feb, 2019 1 commit
  7. 28 Jan, 2019 2 commits
  9. 27 Jan, 2019 1 commit
  11. 21 Jan, 2019 1 commit
  13. 17 Jan, 2019 1 commit
  15. 16 Jan, 2019 1 commit
  17. 13 Jan, 2019 1 commit
  19. 07 Jan, 2019 1 commit
  21. 06 Jan, 2019 4 commits
  23. 23 Dec, 2018 1 commit
  25. 19 Dec, 2018 2 commits
  27. 16 Dec, 2018 5 commits
  29. 13 Dec, 2018 1 commit
    • Rob Herring's avatar
      kbuild: Add support for DT binding schema checks · 4f0e3a57
      Rob Herring authored 
      This adds the build infrastructure for checking DT binding schema
documents and validating dts files using the binding schema.

Check DT binding schema documents:
make dt_binding_check

Build dts files and check using DT binding schema:
make dtbs_check

Optionally, DT_SCHEMA_FILES can be passed in with a schema file(s) to
use for validation. This makes it easier to find and fix errors
generated by a specific schema.

Currently, the validation targets are separate from a normal build to
avoid a hard dependency on the external DT schema project and because
there are lots of warnings generated.

Cc: Jonathan Corbet <corbet@lwn.net>
Cc: Mark Rutland <mark.rutland@arm.com>
Acked-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
Cc: Michal Marek <michal.lkml@markovi.net>
Cc: linux-doc@vger.kernel.org
Cc: devicetree@vger.kernel.org
Cc: linux-kbuild@vger.kernel.org
Signed-off-by: default avatarRob Herring <robh@kernel.org>
      4f0e3a57
  31. 09 Dec, 2018 1 commit
  33. 08 Dec, 2018 1 commit
  35. 02 Dec, 2018 1 commit
  37. 01 Dec, 2018 4 commits
    • Masahiro Yamada's avatar
      kbuild: let fixdep directly write to .*.cmd files · 392885ee
      Masahiro Yamada authored 
      Currently, fixdep writes dependencies to .*.tmp, which is renamed to
.*.cmd after everything succeeds. This is a very safe way to avoid
corrupted .*.cmd files. The if_changed_dep has carried this safety
mechanism since it was added in 2002.

If fixdep fails for some reasons or a user terminates the build while
fixdep is running, the incomplete output from the fixdep could be
troublesome.

This is my insight about some bad scenarios:

[1] If the compiler succeeds to generate *.o file, but fixdep fails
    to write necessary dependencies to .*.cmd file, Make will miss
    to rebuild the object when headers or CONFIG options are changed.
    In this case, fixdep should not generate .*.cmd file at all so
    that 'arg-check' will surely trigger the rebuild of the object.

[2] A partially constructed .*.cmd file may not be a syntactically
    correct makefile. The next time Make runs, it would include it,
    then fail to parse it. Once this happens, 'make clean' is be the
    only way to fix it.

In fact, [1] is no longer a problem since commit 9c2af1c7 ("kbuild:
add .DELETE_ON_ERROR special target"). Make deletes a target file on
any failure in its recipe. Because fixdep is a part of the recipe of
*.o target, if it fails, the *.o is deleted anyway. However, I am a
bit worried about the slight possibility of [2].

So, here is a solution. Let fixdep directly write to a .*.cmd file,
but allow makefiles to include it only when its corresponding target
exists.

This effectively reverts commit 2982c953 ("kbuild: remove redundant
$(wildcard ...) for cmd_files calculation"), and commit 00d78ab2
("kbuild: remove dead code in cmd_files calculation in top Makefile")
because now we must check the presence of targets.
Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      392885ee
    • Masahiro Yamada's avatar
      kbuild: descend into scripts/gcc-plugins/ via scripts/Makefile · ce2fd53a
      Masahiro Yamada authored 
      Now that 'archprepare' depends on 'scripts', Kbuild can descend into
scripts/gcc-plugins in a more standard way.
Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
Reviewed-by: default avatarKees Cook <keescook@chromium.org>
      ce2fd53a
    • Masahiro Yamada's avatar
      kbuild: make 'archprepare' depend on 'scripts' · 059bc9fc
      Masahiro Yamada authored 
      Before start descending, Kbuild needs to run 'prepare' and 'scripts',
which has been orthogonal to each other.

Going forward, let's consider 'scripts' is a part of the preparation.
This will allow more cleanups.

Move 'scripts' to the prerequisite of 'archprepare', where UML starts
compiling target *.c files.
Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      059bc9fc
    • Masahiro Yamada's avatar
      kbuild: move modpost out of 'scripts' target · 60df1aee
      Masahiro Yamada authored 
      I am eagar to build under the scripts/ directory only with $(HOSTCC),
but scripts/mod/ highly depends on the $(CC) and target arch headers.
That it why the 'scripts' target must depend on 'asm-generic',
'gcc-plugins', and $(autoksyms_h).

Move it to the 'prepare0' stage. I know this is a cheesy workaround,
but better than the current situation.
Signed-off-by: default avatarMasahiro Yamada <yamada.masahiro@socionext.com>
      60df1aee
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7