linux-toradex.git/scripts/gcc-plugins/Kconfig, branch v5.12-rc5

gcc-plugins: simplify GCC plugin-dev capability test

2020-12-04T22:09:55+00:00

Linus pointed out a third of the time in the Kconfig parse stage comes
from the single invocation of cc1plus in scripts/gcc-plugin.sh [1],
and directly testing plugin-version.h for existence cuts down the
overhead a lot. [2]

This commit takes one step further to kill the build test entirely.

The small piece of code was probably intended to test the C++ designated
initializer, which was not supported until C++20.

In fact, with -pedantic option given, both GCC and Clang emit a warning.

$ echo 'class test { public: int test; } test = { .test = 1 };' | g++ -x c++ -pedantic - -fsyntax-only
:1:43: warning: C++ designated initializers only available with '-std=c++2a' or '-std=gnu++2a' [-Wpedantic]
$ echo 'class test { public: int test; } test = { .test = 1 };' | clang++ -x c++ -pedantic - -fsyntax-only
:1:43: warning: designated initializers are a C++20 extension [-Wc++20-designator]
class test { public: int test; } test = { .test = 1 };
                                          ^
1 warning generated.

Otherwise, modern C++ compilers should be able to build the code, and
hopefully skipping this test should not make any practical problem.

Checking the existence of plugin-version.h is still needed to ensure
the plugin-dev package is installed. The test code is now small enough
to be embedded in scripts/gcc-plugins/Kconfig.

[1] https://lore.kernel.org/lkml/CAHk-=wjU4DCuwQ4pXshRbwDCUQB31ScaeuDo1tjoZ0_PjhLHzQ@mail.gmail.com/
[2] https://lore.kernel.org/lkml/CAHk-=whK0aQxs6Q5ijJmYF1n2ch8cVFSUzU5yUM_HOjig=+vnw@mail.gmail.com/

Reported-by: Linus Torvalds 
Signed-off-by: Masahiro Yamada 
Signed-off-by: Kees Cook 
Link: https://lore.kernel.org/r/20201203125700.161354-1-masahiroy@kernel.org

gcc-plugins: fix gcc-plugins directory path in documentation

2020-06-28T03:16:55+00:00

Fix typos "plgins" -> "plugins".

Signed-off-by: Masahiro Yamada 
Acked-by: Kees Cook

compiler/gcc: Raise minimum GCC version for kernel builds to 4.8

2020-04-15T20:36:20+00:00

It is very rare to see versions of GCC prior to 4.8 being used to build
the mainline kernel. These old compilers are also know to have codegen
issues which can lead to silent miscompilation:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58145

Raise the minimum GCC version for kernel build to 4.8 and remove some
tautological Kconfig dependencies as a consequence.

Cc: Masahiro Yamada 
Acked-by: Arnd Bergmann 
Reviewed-by: Nick Desaulniers 
Signed-off-by: Will Deacon

gcc-plugins: drop support for GCC <= 4.7

2020-04-08T15:13:45+00:00

Nobody was opposed to raising minimum GCC version to 4.8 [1]
So, we will drop GCC <= 4.7 support sooner or later.

We always use C++ compiler for building plugins for GCC >= 4.8.

This commit drops the plugin support for GCC <= 4.7 a bit earlier,
which allows us to dump lots of code.

[1] https://lkml.org/lkml/2020/1/23/545

Signed-off-by: Masahiro Yamada 
Acked-by: Kees Cook

docs: move gcc-plugins to the kbuild manual

2020-03-10T17:20:46+00:00

Information about GCC plugins is relevant to kernel building, so move this
document to the kbuild manual.

Acked-by: Masahiro Yamada 
Signed-off-by: Jonathan Corbet

gcc-plugins: make it possible to disable CONFIG_GCC_PLUGINS again

2020-01-02T21:30:14+00:00

I noticed that randconfig builds with gcc no longer produce a lot of
ccache hits, unlike with clang, and traced this back to plugins
now being enabled unconditionally if they are supported.

I am now working around this by adding

   export CCACHE_COMPILERCHECK=/usr/bin/size -A %compiler%

to my top-level Makefile. This changes the heuristic that ccache uses
to determine whether the plugins are the same after a 'make clean'.

However, it also seems that being able to just turn off the plugins is
generally useful, at least for build testing it adds noticeable overhead
but does not find a lot of bugs additional bugs, and may be easier for
ccache users than my workaround.

Fixes: 9f671e58159a ("security: Create "kernel hardening" config area")
Signed-off-by: Arnd Bergmann 
Acked-by: Ard Biesheuvel 
Reviewed-by: Masahiro Yamada 
Link: https://lore.kernel.org/r/20191211133951.401933-1-arnd@arndb.de
Cc: stable@vger.kernel.org
Signed-off-by: Kees Cook

docs: move gcc_plugins.txt to core-api and rename to .rst

2019-07-15T12:20:27+00:00

The gcc_plugins.txt file is already a ReST file. Move it
to the core-api book while renaming it.

Signed-off-by: Mauro Carvalho Chehab 
Acked-by: Kees Cook

treewide: Add SPDX license identifier - Makefile/Kconfig

2019-05-21T08:50:46+00:00

Add SPDX license identifiers to all Make/Kconfig files which:

 - Have no license information of any form

These files fall under the project license, GPL v2 only. The resulting SPDX
license identifier is:

  GPL-2.0-only

Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

security: Move stackleak config to Kconfig.hardening

2019-04-24T21:00:56+00:00

This moves the stackleak plugin options to Kconfig.hardening's memory
initialization menu.

Signed-off-by: Kees Cook 
Reviewed-by: Alexander Popov 
Acked-by: Masahiro Yamada

security: Create "kernel hardening" config area

2019-04-24T20:45:49+00:00

Right now kernel hardening options are scattered around various Kconfig
files. This can be a central place to collect these kinds of options
going forward. This is initially populated with the memory initialization
options from the gcc-plugins.

Signed-off-by: Kees Cook 
Acked-by: Masahiro Yamada