1. 27 2月, 2019 7 次提交
  2. 20 2月, 2019 4 次提交
    • M
      kbuild: turn '/' into an alias of './' · 6d3c94e4
      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>
      6d3c94e4
    • M
      kbuild: set KBUILD_MODULES=1 all the time for single target %/ · 648ad9b1
      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>
      648ad9b1
    • N
      kbuild: clang: choose GCC_TOOLCHAIN_DIR not on LD · ad15006c
      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>
      ad15006c
    • M
      kbuild: Disable extra debugging info in .s output · 1e88e415
      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>
      1e88e415
  3. 19 2月, 2019 1 次提交
  4. 28 1月, 2019 3 次提交
  5. 21 1月, 2019 1 次提交
  6. 17 1月, 2019 1 次提交
  7. 16 1月, 2019 1 次提交
  8. 14 1月, 2019 1 次提交
  9. 07 1月, 2019 1 次提交
  10. 06 1月, 2019 4 次提交
  11. 24 12月, 2018 1 次提交
  12. 19 12月, 2018 2 次提交
  13. 17 12月, 2018 1 次提交
  14. 16 12月, 2018 4 次提交
  15. 13 12月, 2018 1 次提交
    • R
      kbuild: Add support for DT binding schema checks · 4f0e3a57
      Rob Herring 提交于
      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: NMasahiro 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: NRob Herring <robh@kernel.org>
      4f0e3a57
  16. 10 12月, 2018 1 次提交
  17. 08 12月, 2018 1 次提交
  18. 03 12月, 2018 1 次提交
  19. 01 12月, 2018 4 次提交
    • M
      kbuild: let fixdep directly write to .*.cmd files · 392885ee
      Masahiro Yamada 提交于
      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: NMasahiro Yamada <yamada.masahiro@socionext.com>
      392885ee
    • M
      kbuild: descend into scripts/gcc-plugins/ via scripts/Makefile · ce2fd53a
      Masahiro Yamada 提交于
      Now that 'archprepare' depends on 'scripts', Kbuild can descend into
      scripts/gcc-plugins in a more standard way.
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Reviewed-by: NKees Cook <keescook@chromium.org>
      ce2fd53a
    • M
      kbuild: make 'archprepare' depend on 'scripts' · 059bc9fc
      Masahiro Yamada 提交于
      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: NMasahiro Yamada <yamada.masahiro@socionext.com>
      059bc9fc
    • M
      kbuild: move modpost out of 'scripts' target · 60df1aee
      Masahiro Yamada 提交于
      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: NMasahiro Yamada <yamada.masahiro@socionext.com>
      60df1aee