1. 20 2月, 2019 1 次提交
    • 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
  2. 19 2月, 2019 1 次提交
  3. 28 1月, 2019 3 次提交
  4. 21 1月, 2019 1 次提交
  5. 17 1月, 2019 1 次提交
  6. 16 1月, 2019 1 次提交
  7. 14 1月, 2019 1 次提交
  8. 07 1月, 2019 1 次提交
  9. 06 1月, 2019 4 次提交
  10. 24 12月, 2018 1 次提交
  11. 19 12月, 2018 2 次提交
  12. 17 12月, 2018 1 次提交
  13. 16 12月, 2018 4 次提交
  14. 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
  15. 10 12月, 2018 1 次提交
  16. 08 12月, 2018 1 次提交
  17. 03 12月, 2018 1 次提交
  18. 01 12月, 2018 7 次提交
    • 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
    • M
      kbuild: fix UML build error with CONFIG_GCC_PLUGINS · 65bba042
      Masahiro Yamada 提交于
      UML fails to build with CONFIG_GCC_PLUGINS=y.
      
      $ make -s ARCH=um mrproper
      $ make -s ARCH=um allmodconfig
      $ make ARCH=um
        UPD     include/generated/uapi/linux/version.h
        WRAP    arch/x86/include/generated/uapi/asm/bpf_perf_event.h
        WRAP    arch/x86/include/generated/uapi/asm/poll.h
        WRAP    arch/x86/include/generated/asm/dma-contiguous.h
        WRAP    arch/x86/include/generated/asm/early_ioremap.h
        WRAP    arch/x86/include/generated/asm/export.h
        WRAP    arch/x86/include/generated/asm/mcs_spinlock.h
        WRAP    arch/x86/include/generated/asm/mm-arch-hooks.h
        SYSTBL  arch/x86/include/generated/asm/syscalls_32.h
        SYSHDR  arch/x86/include/generated/asm/unistd_32_ia32.h
        SYSHDR  arch/x86/include/generated/asm/unistd_64_x32.h
        SYSTBL  arch/x86/include/generated/asm/syscalls_64.h
        SYSHDR  arch/x86/include/generated/uapi/asm/unistd_32.h
        SYSHDR  arch/x86/include/generated/uapi/asm/unistd_64.h
        SYSHDR  arch/x86/include/generated/uapi/asm/unistd_x32.h
        HOSTCC  scripts/unifdef
        CC      arch/x86/um/user-offsets.s
      cc1: error: cannot load plugin ./scripts/gcc-plugins/cyc_complexity_plugin.so
      ./scripts/gcc-plugins/cyc_complexity_plugin.so: cannot open shared object file: No such file or directory
      cc1: error: cannot load plugin ./scripts/gcc-plugins/structleak_plugin.so
      ./scripts/gcc-plugins/structleak_plugin.so: cannot open shared object file: No such file or directory
      cc1: error: cannot load plugin ./scripts/gcc-plugins/latent_entropy_plugin.so
      ./scripts/gcc-plugins/latent_entropy_plugin.so: cannot open shared object file: No such file or directory
      cc1: error: cannot load plugin ./scripts/gcc-plugins/randomize_layout_plugin.so
      ./scripts/gcc-plugins/randomize_layout_plugin.so: cannot open shared object file: No such file or directory
      make[1]: *** [scripts/Makefile.build;119: arch/x86/um/user-offsets.s] Error 1
      make: *** [arch/um/Makefile;152: arch/x86/um/user-offsets.s] Error 2
      
      Reorder the preparation stage (with cleanups) to make sure gcc-plugins
      is built before descending to arch/x86/um/.
      
      Fixes: 6b90bd4b ("GCC plugin infrastructure")
      Reported-by: Nkbuild test robot <lkp@intel.com>
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      65bba042
    • M
      kbuild: fix single target build for external module · e07db28e
      Masahiro Yamada 提交于
      Building a single target in an external module fails due to missing
      .tmp_versions directory.
      
      For example,
      
        $ make -C /lib/modules/$(uname -r)/build M=$PWD foo.o
      
      will fail in the following way:
      
        CC [M]  /home/masahiro/foo/foo.o
      /bin/sh: 1: cannot create /home/masahiro/foo/.tmp_versions/foo.mod: Directory nonexistent
      
      This is because $(cmd_crmodverdir) is executed only before building
      /, %/, %.ko single targets of external modules. Create .tmp_versions
      in the 'prepare' target.
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      e07db28e
    • M
      kbuild: announce removal of SUBDIRS if used · 0126be38
      Masahiro Yamada 提交于
      SUBDIRS has been kept as a backward compatibility since
      commit ("[PATCH] kbuild: external module support") in 2002.
      
      We do not need multiple ways to do the same thing, so I will remove
      SUBDIRS after the Linux 5.3 release. I cleaned up in-tree code, and
      updated the document so that nobody would try to use it.
      
      Meanwhile, display the following warning if SUBDIRS is used.
      
      Makefile:189: ================= WARNING ================
      Makefile:190: 'SUBDIRS' will be removed after Linux 5.3
      Makefile:191: Please use 'M=' or 'KBUILD_EXTMOD' instead
      Makefile:192: ==========================================
      Signed-off-by: NMasahiro Yamada <yamada.masahiro@socionext.com>
      Acked-by: Boris Brezillon <boris.brezillon@bootlin.com> # for scx200_docflash.c
      Acked-by: Guenter Roeck <linux@roeck-us.net> # for scx200_wdt.c
      0126be38
  19. 26 11月, 2018 1 次提交
  20. 19 11月, 2018 1 次提交
  21. 14 11月, 2018 3 次提交
  22. 12 11月, 2018 1 次提交
  23. 05 11月, 2018 1 次提交