1. 31 Jul, 2021 1 commit
  2. 28 Jul, 2021 1 commit
  3. 25 Jul, 2021 2 commits
  4. 20 Jul, 2021 2 commits
  5. 19 Jul, 2021 1 commit
  6. 14 Jul, 2021 2 commits
  7. 07 Jul, 2021 1 commit
  8. 27 Jun, 2021 1 commit
  9. 20 Jun, 2021 1 commit
  10. 14 Jun, 2021 1 commit
  11. 13 Jun, 2021 1 commit
  12. 06 Jun, 2021 1 commit
  13. 30 May, 2021 1 commit
  14. 24 May, 2021 1 commit
    • Nick Desaulniers's avatar
      Makefile: LTO: have linker check -Wframe-larger-than · 24845dcb
      Nick Desaulniers authored
      
      -Wframe-larger-than= requires stack frame information, which the
      frontend cannot provide. This diagnostic is emitted late during
      compilation once stack frame size is available.
      
      When building with LTO, the frontend simply lowers C to LLVM IR and does
      not have stack frame information, so it cannot emit this diagnostic.
      When the linker drives LTO, it restarts optimizations and lowers LLVM IR
      to object code. At that point, it has stack frame information but
      doesn't know to check for a specific max stack frame size.
      
      I consider this a bug in LLVM that we need to fix. There are some
      details we're working out related to LTO such as which value to use when
      there are multiple different values specified per TU, or how to
      propagate these to compiler synthesized routines properly, if at all.
      
      Until it's fixed, ensure we don't miss these. At that point we can wrap
      this in a compiler version guard or revert this based on the minimum
      support version of Clang.
      
      The error message is not generated during link:
        LTO     vmlinux.o
      ld.lld: warning: stack size limit exceeded (8224) in foobarbaz
      
      Cc: Sami Tolvanen <samitolvanen@google.com>
      Reported-by: default avatarCandle Sun <candlesea@gmail.com>
      Suggested-by: default avatarFangrui Song <maskray@google.com>
      Signed-off-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      Signed-off-by: default avatarKees Cook <keescook@chromium.org>
      Link: https://lore.kernel.org/r/20210312010942.1546679-1-ndesaulniers@google.com
      24845dcb
  15. 23 May, 2021 1 commit
  16. 16 May, 2021 1 commit
  17. 09 May, 2021 1 commit
  18. 05 May, 2021 3 commits
  19. 03 May, 2021 1 commit
  20. 01 May, 2021 2 commits
  21. 25 Apr, 2021 1 commit
  22. 24 Apr, 2021 13 commits
    • Nathan Chancellor's avatar
      kbuild: Add $(KBUILD_HOSTLDFLAGS) to 'has_libelf' test · f634ca65
      Nathan Chancellor authored
      Normally, invocations of $(HOSTCC) include $(KBUILD_HOSTLDFLAGS), which
      in turn includes $(HOSTLDFLAGS), which allows users to pass in their own
      flags when linking. However, the 'has_libelf' test does not, meaning
      that if a user requests a specific linker via HOSTLDFLAGS=-fuse-ld=...,
      it is not respected and the build might error.
      
      For example, if a user building with clang wants to use all of the LLVM
      tools without any GNU tools, they might remove all of the GNU tools from
      their system or PATH then build with
      
      $ make HOSTLDFLAGS=-fuse-ld=lld LLVM=1 LLVM_IAS=1
      
      which says use all of the LLVM tools, the integrated assembler, and
      ld.lld for linking host executables. Without this change, the build will
      error because $(HOSTCC) uses its default linker, rather than the one
      requested via -fuse-ld=..., which is GNU ld in clang's case in a default
      configuration.
      
      error: Cannot generate ORC metadata for CONFIG_UNWINDER_ORC=y, please
      install libelf-dev, libelf-devel or elfutils-libelf-devel
      make[1]: *** [Makefile:1260: prepare-objtool] Error 1
      
      Add $(KBUILD_HOSTLDFLAGS) to the 'has_libelf' test so that the linker
      choice is respected.
      
      Link: https://github.com/ClangBuiltLinux/linux/issues/479
      
      Signed-off-by: default avatarNathan Chancellor <nathan@kernel.org>
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      f634ca65
    • Masahiro Yamada's avatar
      kbuild: merge scripts/Makefile.modsign to scripts/Makefile.modinst · 961ab4a3
      Masahiro Yamada authored
      scripts/Makefile.modsign is a subset of scripts/Makefile.modinst,
      and duplicates the code. Let's merge them.
      
      By the way, you do not need to run 'make modules_sign' explicitly
      because modules are signed as a part of 'make modules_install' when
      CONFIG_MODULE_SIG_ALL=y. If CONFIG_MODULE_SIG_ALL=n, mod_sign_cmd is
      set to 'true', so 'make modules_sign' is not functional.
      
      In my understanding, the reason of still keeping this is to handle
      corner cases like commit 64178cb6
      
       ("builddeb: fix stripped module
      signatures if CONFIG_DEBUG_INFO and CONFIG_MODULE_SIG_ALL are set").
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      961ab4a3
    • Masahiro Yamada's avatar
      kbuild: move module strip/compression code into scripts/Makefile.modinst · 65ce9c38
      Masahiro Yamada authored
      
      Both mod_strip_cmd and mod_compress_cmd are only used in
      scripts/Makefile.modinst, hence there is no good reason to define them
      in the top Makefile. Move the relevant code to scripts/Makefile.modinst.
      
      Also, show separate log messages for each of install, strip, sign, and
      compress.
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      65ce9c38
    • Masahiro Yamada's avatar
      kbuild: refactor scripts/Makefile.modinst · ccae4cfa
      Masahiro Yamada authored
      
      scripts/Makefile.modinst is ugly and weird in multiple ways; it
      specifies real files $(modules) as phony, makes directory manipulation
      needlessly too complicated.
      
      Clean up the Makefile code, and show the full path of installed modules
      in the log.
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      ccae4cfa
    • Masahiro Yamada's avatar
      kbuild: rename extmod-prefix to extmod_prefix · 7f69180b
      Masahiro Yamada authored
      
      This seems to be useful in sub-make as well. As a preparation of
      exporting it, rename extmod-prefix to extmod_prefix because exported
      variables cannot contain hyphens.
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      Reviewed-by: default avatarNick Desaulniers <ndesaulniers@google.com>
      7f69180b
    • Masahiro Yamada's avatar
      kbuild: check module name conflict for external modules as well · 1a998be6
      Masahiro Yamada authored
      
      If there are multiple modules with the same name in the same external
      module tree, there is ambiguity about which one will be loaded, and
      very likely something odd is happening.
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      1a998be6
    • Masahiro Yamada's avatar
      kbuild: show the target directory for depmod log · 3ac42b21
      Masahiro Yamada authored
      
      It is clearer to show the directory which depmod will work on.
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      3ac42b21
    • Masahiro Yamada's avatar
      kbuild: unify modules(_install) for in-tree and external modules · 3e3005df
      Masahiro Yamada authored
      
      If you attempt to build or install modules ('make modules(_install)'
      with CONFIG_MODULES disabled, you will get a clear error message, but
      nothing for external module builds.
      
      Factor out the modules and modules_install rules into the common part,
      so you will get the same error message when you try to build external
      modules with CONFIG_MODULES=n.
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      3e3005df
    • Masahiro Yamada's avatar
      kbuild: remove unneeded mkdir for external modules_install · 4b97ec0e
      Masahiro Yamada authored
      
      scripts/Makefile.modinst creates directories as needed.
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      4b97ec0e
    • Masahiro Yamada's avatar
      kbuild: generate Module.symvers only when vmlinux exists · 69bc8d38
      Masahiro Yamada authored
      
      The external module build shows the following warning if Module.symvers
      is missing in the kernel tree.
      
        WARNING: Symbol version dump "Module.symvers" is missing.
                 Modules may not have dependencies or modversions.
      
      I think this is an important heads-up because the resulting modules may
      not work as expected. This happens when you did not build the entire
      kernel tree, for example, you might have prepared the minimal setups
      for external modules by 'make defconfig && make modules_preapre'.
      
      A problem is that 'make modules' creates Module.symvers even without
      vmlinux. In this case, that warning is suppressed since Module.symvers
      already exists in spite of its incomplete content.
      
      The incomplete (i.e. invalid) Module.symvers should not be created.
      
      This commit changes the second pass of modpost to dump symbols into
      modules-only.symvers. The final Module.symvers is created by
      concatenating vmlinux.symvers and modules-only.symvers if both exist.
      
      Module.symvers is supposed to collect symbols from both vmlinux and
      modules. It might be a bit confusing, and I am not quite sure if it
      is an official interface, but presumably it is difficult to rename it
      because some tools (e.g. kmod) parse it.
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      69bc8d38
    • Masahiro Yamada's avatar
      kbuild: check the minimum assembler version in Kconfig · ba64beb1
      Masahiro Yamada authored
      Documentation/process/changes.rst defines the minimum assembler version
      (binutils version), but we have never checked it in the build time.
      
      Kbuild never invokes 'as' directly because all assembly files in the
      kernel tree are *.S, hence must be preprocessed. I do not expect
      raw assembly source files (*.s) would be added to the kernel tree.
      
      Therefore, we always use $(CC) as the assembler driver, and commit
      aa824e0c ("kbuild: remove AS variable") removed 'AS'. However,
      we are still interested in the version of the assembler acting behind.
      
      As usual, the --version option prints the version string.
      
        $ as --version | head -n 1
        GNU assembler (GNU Binutils for Ubuntu) 2.35.1
      
      But, we do not have $(AS). So, we can add the -Wa prefix so that
      $(CC) passes --version down to the backing assembler.
      
        $ gcc -Wa,--version | head -n 1
        gcc: fatal error: no input files
        compilation terminated.
      
      OK, we need to input something to satisfy gcc.
      
        $ gcc -Wa,--...
      ba64beb1
    • Masahiro Yamada's avatar
      kbuild: replace sed with $(subst ) or $(patsubst ) · 6e0839fd
      Masahiro Yamada authored
      
      For simple text replacement, it is better to use a built-in function
      instead of sed if possible. You can save one process forking.
      
      I do not mean to replace all sed invocations because GNU Make itself
      does not support regular expression (unless you use guile).
      
      I just replaced simple ones.
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      6e0839fd
    • Nathan Chancellor's avatar
      Makefile: Only specify '--prefix=' when building with clang + GNU as · eec08090
      Nathan Chancellor authored
      When building with LLVM_IAS=1, there is no point to specifying
      '--prefix=' because that flag is only used to find GNU cross tools,
      which will not be used indirectly when using the integrated assembler.
      All of the tools are invoked directly from PATH or a full path specified
      via the command line, which does not depend on the value of '--prefix='.
      
      Sharing commands to reproduce issues becomes a little bit easier without
      a '--prefix=' value because that '--prefix=' value is specific to a
      user's machine due to it being an absolute path.
      
      Some further notes from Fangrui Song:
      
        clang can spawn GNU as (if -f?no-integrated-as is specified) and GNU
        objcopy (-f?no-integrated-as and -gsplit-dwarf and -g[123]).
        objcopy is only used for GNU as assembled object files.
        With integrated assembler, the object file streamer creates .o and
        .dwo simultaneously.
        With GNU as, two objcopy commands are needed to extract .debug*.dwo to
        .dwo files && another command to remove .debug*.dwo sections.
      
      A small consequence of this change (to keep things simple) is that
      '--prefix=' will always be specified now, even with a native build, when
      it was not before. This should not be an issue due to the way that the
      Makefile searches for the prefix (based on elfedit's location). This
      ends up improving the experience for host builds because PATH is better
      respected and matches GCC's behavior more closely. See the below thread
      for more details:
      
      https://lore.kernel.org/r/20210205213651.GA16907@Ryzen-5-4500U.localdomain/
      
      Signed-off-by: default avatarNathan Chancellor <nathan@kernel.org>
      Signed-off-by: default avatarMasahiro Yamada <masahiroy@kernel.org>
      eec08090