Skip to content

K
Kernel

openeuler / Kernel
1 年多 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 15 7月, 2021 1 次提交
    • G
      Makefile: Enable -Wimplicit-fallthrough for Clang · b7eb335e
      由 Gustavo A. R. Silva 提交于 
      With the recent fixes for fallthrough warnings, it is now possible to
enable -Wimplicit-fallthrough for Clang.

It's important to mention that since we have adopted the use of the
pseudo-keyword macro fallthrough; we also want to avoid having more
/* fall through */ comments being introduced. Notice that contrary
to GCC, Clang doesn't recognize any comments as implicit fall-through
markings when the -Wimplicit-fallthrough option is enabled. So, in
order to avoid having more comments being introduced, we have to use
the option -Wimplicit-fallthrough=5 for GCC, which similar to Clang,
will cause a warning in case a code comment is intended to be used
as a fall-through marking.
Co-developed-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NGustavo A. R. Silva <gustavoars@kernel.org>
      b7eb335e
  3. 12 7月, 2021 1 次提交
  5. 28 6月, 2021 1 次提交
  7. 21 6月, 2021 1 次提交
  9. 17 6月, 2021 1 次提交
    • M
      kbuild: remove trailing slashes from $(KBUILD_EXTMOD) · 74ee585b
      由 Masahiro Yamada 提交于 
      M= (or KBUILD_EXTMOD) generally expects a directory path without any
trailing slashes, like M=a/b/c.

If you add a trailing slash, like M=a/b/c/, you will get ugly build
logs (two slashes in a series), but it still works fine as long as it
is consistent between 'make modules' and 'make modules_install'.

The following commands correctly build and install the modules.

  $ make M=a/b/c/ modules
  $ sudo make M=a/b/c/ modules_install

Since commit ccae4cfa ("kbuild: refactor scripts/Makefile.modinst"),
a problem happens if you add a trailing slash only for modules_install.

  $ make M=a/b/c modules
  $ sudo make M=a/b/c/ modules_install

No module is installed in this case, Johannes Berg reported. [1]

Trim any trailing slashes from $(KBUILD_EXTMOD).

I used the 'dirname' command to remove all the trailing slashes in
case someone adds more slashes like M=a/b/c/////. The Make's built-in
function, $(dir ...) cannot take care of such a case.

[1]: https://lore.kernel.org/lkml/10cc8522b27a051e6a9c3e158a4c4b6414fd04a0.camel@sipsolutions.net/

Fixes: ccae4cfa ("kbuild: refactor scripts/Makefile.modinst")
Reported-by: NJohannes Berg <johannes@sipsolutions.net>
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
      74ee585b
  11. 15 6月, 2021 1 次提交
  13. 14 6月, 2021 1 次提交
  15. 08 6月, 2021 1 次提交
  17. 07 6月, 2021 1 次提交
  19. 31 5月, 2021 1 次提交
  21. 27 5月, 2021 1 次提交
  23. 26 5月, 2021 1 次提交
  25. 25 5月, 2021 1 次提交
    • N
      Makefile: LTO: have linker check -Wframe-larger-than · 24845dcb
      由 Nick Desaulniers 提交于 
      -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: 八两学士's avatarCandle Sun <candlesea@gmail.com>
Suggested-by: NFangrui Song <maskray@google.com>
Signed-off-by: NNick Desaulniers <ndesaulniers@google.com>
Signed-off-by: NKees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20210312010942.1546679-1-ndesaulniers@google.com
      24845dcb
  27. 24 5月, 2021 4 次提交
  29. 17 5月, 2021 1 次提交
  31. 10 5月, 2021 1 次提交
  33. 06 5月, 2021 3 次提交
  35. 03 5月, 2021 1 次提交
  37. 01 5月, 2021 2 次提交
  39. 26 4月, 2021 1 次提交
  41. 25 4月, 2021 14 次提交
    • N
      kbuild: Add $(KBUILD_HOSTLDFLAGS) to 'has_libelf' test · f634ca65
      由 Nathan Chancellor 提交于 
      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/479Signed-off-by: NNathan Chancellor <nathan@kernel.org>
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
      f634ca65
    • M
      kbuild: merge scripts/Makefile.modsign to scripts/Makefile.modinst · 961ab4a3
      由 Masahiro Yamada 提交于 
      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: NMasahiro Yamada <masahiroy@kernel.org>
      961ab4a3
    • M
      kbuild: move module strip/compression code into scripts/Makefile.modinst · 65ce9c38
      由 Masahiro Yamada 提交于 
      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: NMasahiro Yamada <masahiroy@kernel.org>
      65ce9c38
    • M
      kbuild: refactor scripts/Makefile.modinst · ccae4cfa
      由 Masahiro Yamada 提交于 
      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: NMasahiro Yamada <masahiroy@kernel.org>
      ccae4cfa
    • M
      kbuild: rename extmod-prefix to extmod_prefix · 7f69180b
      由 Masahiro Yamada 提交于 
      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: NMasahiro Yamada <masahiroy@kernel.org>
Reviewed-by: NNick Desaulniers <ndesaulniers@google.com>
      7f69180b
    • M
      kbuild: check module name conflict for external modules as well · 1a998be6
      由 Masahiro Yamada 提交于 
      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: NMasahiro Yamada <masahiroy@kernel.org>
      1a998be6
    • M
      kbuild: show the target directory for depmod log · 3ac42b21
      由 Masahiro Yamada 提交于 
      It is clearer to show the directory which depmod will work on.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
      3ac42b21
    • M
      kbuild: unify modules(_install) for in-tree and external modules · 3e3005df
      由 Masahiro Yamada 提交于 
      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: NMasahiro Yamada <masahiroy@kernel.org>
      3e3005df
    • M
      kbuild: remove unneeded mkdir for external modules_install · 4b97ec0e
      由 Masahiro Yamada 提交于 
      scripts/Makefile.modinst creates directories as needed.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
      4b97ec0e
    • M
      kbuild: generate Module.symvers only when vmlinux exists · 69bc8d38
      由 Masahiro Yamada 提交于 
      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: NMasahiro Yamada <masahiroy@kernel.org>
      69bc8d38
    • M
      kbuild: check the minimum assembler version in Kconfig · ba64beb1
      由 Masahiro Yamada 提交于 
      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,--version -c -x assembler /dev/null -o /dev/null | head -n 1
  GNU assembler (GNU Binutils for Ubuntu) 2.35.1

The combination of Clang and GNU assembler works in the same way:

  $ clang -no-integrated-as -Wa,--version -c -x assembler /dev/null -o /dev/null | head -n 1
  GNU assembler (GNU Binutils for Ubuntu) 2.35.1

Clang with the integrated assembler fails like this:

  $ clang -integrated-as -Wa,--version -c -x assembler /dev/null -o /dev/null | head -n 1
  clang: error: unsupported argument '--version' to option 'Wa,'

For the last case, checking the error message is fragile. If the
proposal for -Wa,--version support [1] is accepted, this may not be
even an error in the future.

One easy way is to check if -integrated-as is present in the passed
arguments. We did not pass -integrated-as to CLANG_FLAGS before, but
we can make it explicit.

Nathan pointed out -integrated-as is the default for all of the
architectures/targets that the kernel cares about, but it goes
along with "explicit is better than implicit" policy. [2]

With all this in my mind, I implemented scripts/as-version.sh to
check the assembler version in Kconfig time.

  $ scripts/as-version.sh gcc
  GNU 23501
  $ scripts/as-version.sh clang -no-integrated-as
  GNU 23501
  $ scripts/as-version.sh clang -integrated-as
  LLVM 0

[1]: https://github.com/ClangBuiltLinux/linux/issues/1320
[2]: https://lore.kernel.org/linux-kbuild/20210307044253.v3h47ucq6ng25iay@archlinux-ax161/Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
Reviewed-by: NNathan Chancellor <nathan@kernel.org>
      ba64beb1
    • M
      kbuild: replace sed with $(subst ) or $(patsubst ) · 6e0839fd
      由 Masahiro Yamada 提交于 
      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: NMasahiro Yamada <masahiroy@kernel.org>
      6e0839fd
    • N
      Makefile: Only specify '--prefix=' when building with clang + GNU as · eec08090
      由 Nathan Chancellor 提交于 
      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: NNathan Chancellor <nathan@kernel.org>
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
      eec08090
    • N
      Makefile: Remove '--gcc-toolchain' flag · c91d4e47
      由 Nathan Chancellor 提交于 
      This flag was originally added to allow clang to find the GNU cross
tools in commit 785f11aa ("kbuild: Add better clang cross build
support"). This flag was not enough to find the tools at times so
'--prefix' was added to the list in commit ef8c4ed9 ("kbuild: allow
to use GCC toolchain not in Clang search path") and improved upon in
commit ca9b31f6 ("Makefile: Fix GCC_TOOLCHAIN_DIR prefix for Clang
cross compilation"). Now that '--prefix' specifies a full path and
prefix, '--gcc-toolchain' serves no purpose because the kernel builds
with '-nostdinc' and '-nostdlib'.

This has been verified with self compiled LLVM 10.0.1 and LLVM 13.0.0 as
well as a distribution version of LLVM 11.1.0 without binutils in the
LLVM toolchain locations.

Link: https://reviews.llvm.org/D97902Signed-off-by: NNathan Chancellor <nathan@kernel.org>
Reviewed-by: NFangrui Song <maskray@google.com>
Reviewed-by: NNick Desaulniers <ndesaulniers@google.com>
Tested-by: NNick Desaulniers <ndesaulniers@google.com>
Tested-by: NSedat Dilek <sedat.dilek@gmail.com>
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
      c91d4e47