Skip to content

K
Kernel

openeuler / Kernel
接近 2 年 前同步成功

通知 8
Star 0
Fork 0
K
Kernel
切换分支/标签
  1. 15 1月, 2021 1 次提交
    • S
      kbuild: add support for Clang LTO · dc5723b0
      由 Sami Tolvanen 提交于 
      This change adds build system support for Clang's Link Time
Optimization (LTO). With -flto, instead of ELF object files, Clang
produces LLVM bitcode, which is compiled into native code at link
time, allowing the final binary to be optimized globally. For more
details, see:

  https://llvm.org/docs/LinkTimeOptimization.html

The Kconfig option CONFIG_LTO_CLANG is implemented as a choice,
which defaults to LTO being disabled. To use LTO, the architecture
must select ARCH_SUPPORTS_LTO_CLANG and support:

  - compiling with Clang,
  - compiling all assembly code with Clang's integrated assembler,
  - and linking with LLD.

While using CONFIG_LTO_CLANG_FULL results in the best runtime
performance, the compilation is not scalable in time or
memory. CONFIG_LTO_CLANG_THIN enables ThinLTO, which allows
parallel optimization and faster incremental builds. ThinLTO is
used by default if the architecture also selects
ARCH_SUPPORTS_LTO_CLANG_THIN:

  https://clang.llvm.org/docs/ThinLTO.html

To enable LTO, LLVM tools must be used to handle bitcode files, by
passing LLVM=1 and LLVM_IAS=1 options to make:

  $ make LLVM=1 LLVM_IAS=1 defconfig
  $ scripts/config -e LTO_CLANG_THIN
  $ make LLVM=1 LLVM_IAS=1

To prepare for LTO support with other compilers, common parts are
gated behind the CONFIG_LTO option, and LTO can be disabled for
specific files by filtering out CC_FLAGS_LTO.
Signed-off-by: NSami Tolvanen <samitolvanen@google.com>
Reviewed-by: NKees Cook <keescook@chromium.org>
Signed-off-by: NKees Cook <keescook@chromium.org>
Link: https://lore.kernel.org/r/20201211184633.3213045-3-samitolvanen@google.com
      dc5723b0
  3. 09 1月, 2021 1 次提交
  5. 02 1月, 2021 1 次提交
  7. 30 12月, 2020 1 次提交
  9. 24 12月, 2020 1 次提交
    • S
      scripts: coccicheck: Correct usage of make coccicheck · d8f6e5c6
      由 Sumera Priyadarsini 提交于 
      The command "make coccicheck C=1 CHECK=scripts/coccicheck" results in the
error:
        ./scripts/coccicheck: line 65: -1: shift count out of range

This happens because every time the C variable is specified,
the shell arguments need to be "shifted" in order to take only
the last argument, which is the C file to test. These shell arguments
mostly comprise flags that have been set in the Makefile. However,
when coccicheck is specified in the make command as a rule, the
number of shell arguments is zero, thus passing the invalid value -1
to the shift command, resulting in an error.

Modify coccicheck to print correct usage of make coccicheck so as to
avoid the error.
Signed-off-by: NSumera Priyadarsini <sylphrenadin@gmail.com>
Signed-off-by: NJulia Lawall <Julia.Lawall@inria.fr>
      d8f6e5c6
  11. 23 12月, 2020 1 次提交
  13. 21 12月, 2020 8 次提交
    • M
      kconfig: fix return value of do_error_if() · 135b4957
      由 Masahiro Yamada 提交于 
      $(error-if,...) is expanded to an empty string. Currently, it relies on
eval_clause() returning xstrdup("") when all attempts for expansion fail,
but the correct implementation is to make do_error_if() return xstrdup("").

Fixes: 1d6272e6 ("kconfig: add 'info', 'warning-if', and 'error-if' built-in functions")
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
      135b4957
    • M
      genksyms: Ignore module scoped _Static_assert() · 9ab55d7f
      由 Marco Elver 提交于 
      The C11 _Static_assert() keyword may be used at module scope, and we
need to teach genksyms about it to not abort with an error. We currently
have a growing number of static_assert() (but also direct usage of
_Static_assert()) users at module scope:

	git grep -E '^_Static_assert\(|^static_assert\(' | grep -v '^tools' | wc -l
	135

More recently, when enabling CONFIG_MODVERSIONS with CONFIG_KCSAN, we
observe a number of warnings:

	WARNING: modpost: EXPORT symbol "<..all kcsan symbols..>" [vmlinux] [...]

When running a preprocessed source through 'genksyms -w' a number of
syntax errors point at usage of static_assert()s. In the case of
kernel/kcsan/encoding.h, new static_assert()s had been introduced which
used expressions that appear to cause genksyms to not even be able to
recover from the syntax error gracefully (as it appears was the case
previously).

Therefore, make genksyms ignore all _Static_assert() and the contained
expression. With the fix, usage of _Static_assert() no longer cause
"syntax error" all over the kernel, and the above modpost warnings for
KCSAN are gone, too.
Signed-off-by: NMarco Elver <elver@google.com>
Acked-by: NNick Desaulniers <ndesaulniers@google.com>
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
      9ab55d7f
    • Q
      modpost: turn static exports into error · b9ed847b
      由 Quentin Perret 提交于 
      Using EXPORT_SYMBOL*() on static functions is fundamentally wrong.
Modpost currently reports that as a warning, but clearly this is not a
pattern we should allow, and all in-tree occurences should have been
fixed by now. So, promote the warn() message to error() to make sure
this never happens again.
Acked-by: NGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: NMatthias Maennich <maennich@google.com>
Signed-off-by: NQuentin Perret <qperret@google.com>
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
      b9ed847b
    • M
      modpost: turn section mismatches to error from fatal() · c7299d98
      由 Masahiro Yamada 提交于 
      There is code that reports static EXPORT_SYMBOL a few lines below.
It is not a good idea to bail out here.

I renamed sec_mismatch_fatal to sec_mismatch_warn_only (with logical
inversion) to match to CONFIG_SECTION_MISMATCH_WARN_ONLY.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
      c7299d98
    • M
      modpost: change license incompatibility to error() from fatal() · d6d692fa
      由 Masahiro Yamada 提交于 
      Change fatal() to error() to continue running to report more possible
issues.

There is no difference in the fact that modpost will fail anyway.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
      d6d692fa
    • M
      modpost: turn missing MODULE_LICENSE() into error · 1d6cd392
      由 Masahiro Yamada 提交于 
      Do not create modules with no license tag.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
      1d6cd392
    • M
      modpost: refactor error handling and clarify error/fatal difference · 0fd3fbad
      由 Masahiro Yamada 提交于 
      We have 3 log functions. fatal() is special because it lets modpost bail
out immediately. The difference between warn() and error() is the only
prefix parts ("WARNING:" vs "ERROR:").

In my understanding, the expected handling of error() is to propagate
the return code of the function to the exit code of modpost, as
check_exports() etc. already does. This is a good manner in general
because we should display as many error messages as possible in a
single run of modpost.

What is annoying about fatal() is that it kills modpost at the first
error. People would need to run Kbuild again and again until they fix
all errors.

But, unfortunately, people tend to do:
"This case should not be allowed. Let's replace warn() with fatal()."

One of the reasons is probably it is tedious to manually hoist the error
code to the main() function.

This commit refactors error() so any single call for it automatically
makes modpost return the error code.

I also added comments in modpost.h for warn(), error(), and fatal().

Please use fatal() only when you have a strong reason to do so.
For example:

  - Memory shortage (i.e. malloc() etc. has failed)
  - The ELF file is broken, and there is no point to continue parsing
  - Something really odd has happened

For general coding errors, please use error().
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
Tested-by: NQuentin Perret <qperret@google.com>
      0fd3fbad
    • M
      modpost: rename merror() to error() · bc72d723
      由 Masahiro Yamada 提交于 
      The log function names, warn(), merror(), fatal() are inconsistent.

Commit 2a116659 ("kbuild: distinguish between errors and warnings
in modpost") intentionally chose merror() to avoid the conflict with
the library function error(). See man page of error(3).

But, we are already causing the conflict with warn() because it is also
a library function. See man page of warn(3). err() would be a problem
for the same reason.

The common technique to work around name conflicts is to use macros.
For example:

    /* in a header */
    #define error(fmt, ...)  __error(fmt, ##__VA_ARGS__)
    #define warn(fmt, ...)   __warn(fmt, ##__VA_ARGS__)

    /* function definition */
    void __error(const char *fmt, ...)
    {
            <our implementation>
    }

    void __warn(const char *fmt, ...)
    {
            <our implementation>
    }

In this way, we can implement our own warn() and error(), still we can
include <error.h> and <err.h> with no problem.

And, commit 93c95e52 ("modpost: rework and consolidate logging
interface") already did that.

Since the log functions are all macros, we can use error() without
causing "conflicting types" errors.
Signed-off-by: NMasahiro Yamada <masahiroy@kernel.org>
      bc72d723
  15. 16 12月, 2020 24 次提交
  17. 13 12月, 2020 1 次提交
  19. 08 12月, 2020 1 次提交