Hi,
GCC plugins should only exist when some compiler feature needs to be
proven but does not exist in either GCC nor Clang. For example, if a
desired feature is already in Clang, it should be added to GCC upstream.
Document this explicitly.
I'll put this in -next unless there are objections. :)
Thanks!
-Kees
Kees Cook (2):
gcc-plugins: Explicitly document purpose and deprecation schedule
gcc-plugins: Remove cyc_complexity
Documentation/kbuild/gcc-plugins.rst | 28 ++++++++-
scripts/Makefile.gcc-plugins | 2 -
scripts/gcc-plugins/Kconfig | 20 +-----
scripts/gcc-plugins/cyc_complexity_plugin.c | 69 ---------------------
security/Kconfig.hardening | 9 ++-
5 files changed, 34 insertions(+), 94 deletions(-)
delete mode 100644 scripts/gcc-plugins/cyc_complexity_plugin.c
--
2.30.2
GCC plugins should only exist when some compiler feature needs to be
proven but does not exist in either GCC nor Clang. For example, if a
desired feature is already in Clang, it should be added to GCC upstream.
Document this explicitly.
Additionally, mark the plugins with matching upstream GCC features as
removable past their respective GCC versions.
Cc: Masahiro Yamada <masahiroy@kernel.org>
Cc: Michal Marek <redacted>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: James Morris <jmorris@namei.org>
Cc: "Serge E. Hallyn" <serge@hallyn.com>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: linux-hardening@vger.kernel.org
Cc: linux-kbuild@vger.kernel.org
Cc: linux-doc@vger.kernel.org
Cc: linux-security-module@vger.kernel.org
Cc: llvm@lists.linux.dev
Signed-off-by: Kees Cook <redacted>
---
Documentation/kbuild/gcc-plugins.rst | 26 ++++++++++++++++++++++++++
scripts/gcc-plugins/Kconfig | 4 ++--
security/Kconfig.hardening | 9 ++++++---
3 files changed, 34 insertions(+), 5 deletions(-)
@@ -32,6 +32,32 @@ This infrastructure was ported from grsecurity [6]_ and PaX [7]_...[7] https://pax.grsecurity.net/+Purpose+=======++GCC plugins are designed to provide a place to experiment with potential+compiler features that are neither in GCC nor Clang upstream. Once+their utility is proven, the goal is to upstream the feature into GCC+(and Clang), and then to finally remove them from the kernel once the+feature is available in all supported versions of GCC.++Specifically, new plugins should implement only features that have no+upstream compiler support (in either GCC or Clang).++When a feature exists in Clang but not GCC, effort should be made to+bring the feature to upstream GCC (rather than just as a kernel-specific+GCC plugin), so the entire ecosystem can benefit from it.++Similarly, even if a feature provided by a GCC plugin does *not* exist+in Clang, but the feature is proven to be useful, effort should be spent+to upstream the feature to GCC (and Clang).++After a feature is available in upstream GCC, the plugin will be made+unbuildable for the corresponding GCC version (and later). Once all+kernel-supported versions of GCC provide the feature, the plugin will+be removed from the kernel.++ Files =====
@@ -37,6 +37,8 @@ config GCC_PLUGIN_CYC_COMPLEXITYconfigGCC_PLUGIN_SANCOVbool+# Plugin can be removed once the kernel only supports GCC 6.1.0++depends on!CC_HAS_SANCOV_TRACE_PChelpThisplugininsertsa__sanitizer_cov_trace_pc()callatthestartofbasicblocks.Itsupportsallgccversionswithpluginsupport(from
@@ -53,7 +53,8 @@ choiceconfigGCC_PLUGIN_STRUCTLEAK_USERbool"zero-init structs marked for userspace (weak)"-depends onGCC_PLUGINS+# Plugin can be removed once the kernel only supports GCC 12++depends onGCC_PLUGINS&&!CC_HAS_AUTO_VAR_INIT_ZEROselectGCC_PLUGIN_STRUCTLEAKhelpZero-initializeanystructuresonthestackcontaining
@@ -64,7 +65,8 @@ choiceconfigGCC_PLUGIN_STRUCTLEAK_BYREFbool"zero-init structs passed by reference (strong)"-depends onGCC_PLUGINS+# Plugin can be removed once the kernel only supports GCC 12++depends onGCC_PLUGINS&&!CC_HAS_AUTO_VAR_INIT_ZEROdepends on!(KASAN&&KASAN_STACK)selectGCC_PLUGIN_STRUCTLEAKhelp
@@ -82,7 +84,8 @@ choiceconfigGCC_PLUGIN_STRUCTLEAK_BYREF_ALLbool"zero-init everything passed by reference (very strong)"-depends onGCC_PLUGINS+# Plugin can be removed once the kernel only supports GCC 12++depends onGCC_PLUGINS&&!CC_HAS_AUTO_VAR_INIT_ZEROdepends on!(KASAN&&KASAN_STACK)selectGCC_PLUGIN_STRUCTLEAKhelp
This plugin has no impact on the resulting binary, is disabled
under COMPILE_TEST, and is not enabled on any builds I'm aware of.
Additionally, given the clarified purpose of GCC plugins in the kernel,
remove cyc_complexity.
Cc: Masahiro Yamada <masahiroy@kernel.org>
Cc: Michal Marek <redacted>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: linux-hardening@vger.kernel.org
Cc: linux-kbuild@vger.kernel.org
Cc: linux-doc@vger.kernel.org
Signed-off-by: Kees Cook <redacted>
---
Documentation/kbuild/gcc-plugins.rst | 2 -
scripts/Makefile.gcc-plugins | 2 -
scripts/gcc-plugins/Kconfig | 16 -----
scripts/gcc-plugins/cyc_complexity_plugin.c | 69 ---------------------
4 files changed, 89 deletions(-)
delete mode 100644 scripts/gcc-plugins/cyc_complexity_plugin.c
@@ -96,7 +96,6 @@ Enable the GCC plugin infrastructure and some plugin(s) you want to use in the kernel config:: CONFIG_GCC_PLUGINS=y- CONFIG_GCC_PLUGIN_CYC_COMPLEXITY=y CONFIG_GCC_PLUGIN_LATENT_ENTROPY=y ...
@@ -115,4 +114,3 @@ The GCC plugins are in scripts/gcc-plugins/. You need to put plugin source files right under scripts/gcc-plugins/. Creating subdirectories is not supported. It must be added to scripts/gcc-plugins/Makefile, scripts/Makefile.gcc-plugins and a relevant Kconfig file.-See the cyc_complexity_plugin.c (CONFIG_GCC_PLUGIN_CYC_COMPLEXITY) GCC plugin.
@@ -19,22 +19,6 @@ menuconfig GCC_PLUGINSifGCC_PLUGINS-configGCC_PLUGIN_CYC_COMPLEXITY-bool"Compute the cyclomatic complexity of a function"ifEXPERT-depends on!COMPILE_TEST# too noisy-help-ThecomplexityMofafunction'scontrolflowgraphisdefinedas:-M=E-N+2P-where--E=thenumberofedges-N=thenumberofnodes-P=thenumberofconnectedcomponents(exitnodes).--Enablingthispluginreportsthecomplexitytostderrduringthe-build.Itmainlyservesasasimpleexampleofhowtocreatea-gccpluginforthekernel.-configGCC_PLUGIN_SANCOVbool# Plugin can be removed once the kernel only supports GCC 6.1.0+
@@ -1,69 +0,0 @@-/*- * Copyright 2011-2016 by Emese Revfy <re.emese@gmail.com>- * Licensed under the GPL v2, or (at your option) v3- *- * Homepage:- * https://github.com/ephox-gcc-plugins/cyclomatic_complexity- *- * https://en.wikipedia.org/wiki/Cyclomatic_complexity- * The complexity M is then defined as:- * M = E - N + 2P- * where- *- * E = the number of edges of the graph- * N = the number of nodes of the graph- * P = the number of connected components (exit nodes).- *- * Usage (4.5 - 5):- * $ make clean; make run- */--#include "gcc-common.h"--__visible int plugin_is_GPL_compatible;--static struct plugin_info cyc_complexity_plugin_info = {- .version = "20160225",- .help = "Cyclomatic Complexity\n",-};--static unsigned int cyc_complexity_execute(void)-{- int complexity;- expanded_location xloc;-- /* M = E - N + 2P */- complexity = n_edges_for_fn(cfun) - n_basic_blocks_for_fn(cfun) + 2;-- xloc = expand_location(DECL_SOURCE_LOCATION(current_function_decl));- fprintf(stderr, "Cyclomatic Complexity %d %s:%s\n", complexity,- xloc.file, DECL_NAME_POINTER(current_function_decl));-- return 0;-}--#define PASS_NAME cyc_complexity--#define NO_GATE-#define TODO_FLAGS_FINISH TODO_dump_func--#include "gcc-generate-gimple-pass.h"--__visible int plugin_init(struct plugin_name_args *plugin_info, struct plugin_gcc_version *version)-{- const char * const plugin_name = plugin_info->base_name;-- PASS_INFO(cyc_complexity, "ssa", 1, PASS_POS_INSERT_AFTER);-- if (!plugin_default_version_check(version, &gcc_version)) {- error(G_("incompatible gcc/plugin versions"));- return 1;- }-- register_callback(plugin_name, PLUGIN_INFO, NULL,- &cyc_complexity_plugin_info);- register_callback(plugin_name, PLUGIN_PASS_MANAGER_SETUP, NULL,- &cyc_complexity_pass_info);-- return 0;-}
From: Miguel Ojeda <hidden> Date: 2021-10-20 17:44:39
On Wed, Oct 20, 2021 at 7:35 PM Kees Cook [off-list ref] wrote:
+Purpose
+=======
Sounds good to me.
config GCC_PLUGIN_SANCOV
bool
+ # Plugin can be removed once the kernel only supports GCC 6.1.0+
Since we are just giving the major in the other cases below, I would
just say GCC 6+ here (the numbering scheme changed in GCC 5 already).
Thanks for adding the versions, by the way -- this is useful long-term
and not always done for other things...
Reviewed-by: Miguel Ojeda <ojeda@kernel.org>
Cheers,
Miguel
On Wed, Oct 20, 2021 at 10:35:53AM -0700, Kees Cook wrote:
GCC plugins should only exist when some compiler feature needs to be
proven but does not exist in either GCC nor Clang. For example, if a
desired feature is already in Clang, it should be added to GCC upstream.
Document this explicitly.
Additionally, mark the plugins with matching upstream GCC features as
removable past their respective GCC versions.
Cc: Masahiro Yamada <masahiroy@kernel.org>
Cc: Michal Marek <redacted>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: James Morris <jmorris@namei.org>
Cc: "Serge E. Hallyn" <serge@hallyn.com>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: linux-hardening@vger.kernel.org
Cc: linux-kbuild@vger.kernel.org
Cc: linux-doc@vger.kernel.org
Cc: linux-security-module@vger.kernel.org
Cc: llvm@lists.linux.dev
Signed-off-by: Kees Cook <redacted>
Seems reasonable to me.
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
One comment below.
@@ -32,6 +32,32 @@ This infrastructure was ported from grsecurity [6]_ and PaX [7]_...[7] https://pax.grsecurity.net/+Purpose+=======++GCC plugins are designed to provide a place to experiment with potential+compiler features that are neither in GCC nor Clang upstream. Once+their utility is proven, the goal is to upstream the feature into GCC+(and Clang), and then to finally remove them from the kernel once the+feature is available in all supported versions of GCC.++Specifically, new plugins should implement only features that have no+upstream compiler support (in either GCC or Clang).++When a feature exists in Clang but not GCC, effort should be made to+bring the feature to upstream GCC (rather than just as a kernel-specific+GCC plugin), so the entire ecosystem can benefit from it.++Similarly, even if a feature provided by a GCC plugin does *not* exist+in Clang, but the feature is proven to be useful, effort should be spent+to upstream the feature to GCC (and Clang).++After a feature is available in upstream GCC, the plugin will be made+unbuildable for the corresponding GCC version (and later). Once all+kernel-supported versions of GCC provide the feature, the plugin will+be removed from the kernel.++ Files =====
@@ -37,6 +37,8 @@ config GCC_PLUGIN_CYC_COMPLEXITYconfigGCC_PLUGIN_SANCOVbool+# Plugin can be removed once the kernel only supports GCC 6.1.0++depends on!CC_HAS_SANCOV_TRACE_PC
This symbol is not user selectable and the one place that does select it
only does so when !CC_HAS_SANCOV_TRACE_PC so this seems pointless to me.
Keep the comment, ditch the depends?
quoted hunk
help
This plugin inserts a __sanitizer_cov_trace_pc() call at the start of
basic blocks. It supports all gcc versions with plugin support (from
@@ -83,8 +85,6 @@ config GCC_PLUGIN_RANDSTRUCT the existing seed and will be removed by a make mrproper or make distclean.- Note that the implementation requires gcc 4.7 or newer.- This plugin was ported from grsecurity/PaX. More information at: * https://grsecurity.net/ * https://pax.grsecurity.net/
@@ -53,7 +53,8 @@ choiceconfigGCC_PLUGIN_STRUCTLEAK_USERbool"zero-init structs marked for userspace (weak)"-depends onGCC_PLUGINS+# Plugin can be removed once the kernel only supports GCC 12++depends onGCC_PLUGINS&&!CC_HAS_AUTO_VAR_INIT_ZEROselectGCC_PLUGIN_STRUCTLEAKhelpZero-initializeanystructuresonthestackcontaining
@@ -64,7 +65,8 @@ choiceconfigGCC_PLUGIN_STRUCTLEAK_BYREFbool"zero-init structs passed by reference (strong)"-depends onGCC_PLUGINS+# Plugin can be removed once the kernel only supports GCC 12++depends onGCC_PLUGINS&&!CC_HAS_AUTO_VAR_INIT_ZEROdepends on!(KASAN&&KASAN_STACK)selectGCC_PLUGIN_STRUCTLEAKhelp
@@ -82,7 +84,8 @@ choiceconfigGCC_PLUGIN_STRUCTLEAK_BYREF_ALLbool"zero-init everything passed by reference (very strong)"-depends onGCC_PLUGINS+# Plugin can be removed once the kernel only supports GCC 12++depends onGCC_PLUGINS&&!CC_HAS_AUTO_VAR_INIT_ZEROdepends on!(KASAN&&KASAN_STACK)selectGCC_PLUGIN_STRUCTLEAKhelp
On Wed, Oct 20, 2021 at 10:35:54AM -0700, Kees Cook wrote:
This plugin has no impact on the resulting binary, is disabled
under COMPILE_TEST, and is not enabled on any builds I'm aware of.
Additionally, given the clarified purpose of GCC plugins in the kernel,
remove cyc_complexity.
Cc: Masahiro Yamada <masahiroy@kernel.org>
Cc: Michal Marek <redacted>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: linux-hardening@vger.kernel.org
Cc: linux-kbuild@vger.kernel.org
Cc: linux-doc@vger.kernel.org
Signed-off-by: Kees Cook <redacted>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
One comment below.
@@ -96,7 +96,6 @@ Enable the GCC plugin infrastructure and some plugin(s) you want to use in the kernel config:: CONFIG_GCC_PLUGINS=y- CONFIG_GCC_PLUGIN_CYC_COMPLEXITY=y CONFIG_GCC_PLUGIN_LATENT_ENTROPY=y ...
There is a comment about the cyc_complexity plugin at the very end of
this file that should also be removed it seems:
"See the cyc_complexity_plugin.c (CONFIG_GCC_PLUGIN_CYC_COMPLEXITY) GCC plugin."
quoted hunk
@@ -115,4 +114,3 @@ The GCC plugins are in scripts/gcc-plugins/. You need to put plugin source files right under scripts/gcc-plugins/. Creating subdirectories is not supported. It must be added to scripts/gcc-plugins/Makefile, scripts/Makefile.gcc-plugins and a relevant Kconfig file.-See the cyc_complexity_plugin.c (CONFIG_GCC_PLUGIN_CYC_COMPLEXITY) GCC plugin.
@@ -19,22 +19,6 @@ menuconfig GCC_PLUGINSifGCC_PLUGINS-configGCC_PLUGIN_CYC_COMPLEXITY-bool"Compute the cyclomatic complexity of a function"ifEXPERT-depends on!COMPILE_TEST# too noisy-help-ThecomplexityMofafunction'scontrolflowgraphisdefinedas:-M=E-N+2P-where--E=thenumberofedges-N=thenumberofnodes-P=thenumberofconnectedcomponents(exitnodes).--Enablingthispluginreportsthecomplexitytostderrduringthe-build.Itmainlyservesasasimpleexampleofhowtocreatea-gccpluginforthekernel.-configGCC_PLUGIN_SANCOVbool# Plugin can be removed once the kernel only supports GCC 6.1.0+
@@ -1,69 +0,0 @@-/*- * Copyright 2011-2016 by Emese Revfy <re.emese@gmail.com>- * Licensed under the GPL v2, or (at your option) v3- *- * Homepage:- * https://github.com/ephox-gcc-plugins/cyclomatic_complexity- *- * https://en.wikipedia.org/wiki/Cyclomatic_complexity- * The complexity M is then defined as:- * M = E - N + 2P- * where- *- * E = the number of edges of the graph- * N = the number of nodes of the graph- * P = the number of connected components (exit nodes).- *- * Usage (4.5 - 5):- * $ make clean; make run- */--#include "gcc-common.h"--__visible int plugin_is_GPL_compatible;--static struct plugin_info cyc_complexity_plugin_info = {- .version = "20160225",- .help = "Cyclomatic Complexity\n",-};--static unsigned int cyc_complexity_execute(void)-{- int complexity;- expanded_location xloc;-- /* M = E - N + 2P */- complexity = n_edges_for_fn(cfun) - n_basic_blocks_for_fn(cfun) + 2;-- xloc = expand_location(DECL_SOURCE_LOCATION(current_function_decl));- fprintf(stderr, "Cyclomatic Complexity %d %s:%s\n", complexity,- xloc.file, DECL_NAME_POINTER(current_function_decl));-- return 0;-}--#define PASS_NAME cyc_complexity--#define NO_GATE-#define TODO_FLAGS_FINISH TODO_dump_func--#include "gcc-generate-gimple-pass.h"--__visible int plugin_init(struct plugin_name_args *plugin_info, struct plugin_gcc_version *version)-{- const char * const plugin_name = plugin_info->base_name;-- PASS_INFO(cyc_complexity, "ssa", 1, PASS_POS_INSERT_AFTER);-- if (!plugin_default_version_check(version, &gcc_version)) {- error(G_("incompatible gcc/plugin versions"));- return 1;- }-- register_callback(plugin_name, PLUGIN_INFO, NULL,- &cyc_complexity_plugin_info);- register_callback(plugin_name, PLUGIN_PASS_MANAGER_SETUP, NULL,- &cyc_complexity_pass_info);-- return 0;-}
From: Nick Desaulniers <ndesaulniers@google.com> Date: 2021-10-20 17:50:46
On Wed, Oct 20, 2021 at 10:35 AM Kees Cook [off-list ref] wrote:
Hi,
GCC plugins should only exist when some compiler feature needs to be
proven but does not exist in either GCC nor Clang. For example, if a
desired feature is already in Clang, it should be added to GCC upstream.
Document this explicitly.
I'll put this in -next unless there are objections. :)
Acked-by: Nick Desaulniers <ndesaulniers@google.com>
On Wed, Oct 20, 2021 at 10:48:59AM -0700, Nathan Chancellor wrote:
On Wed, Oct 20, 2021 at 10:35:54AM -0700, Kees Cook wrote:
quoted
This plugin has no impact on the resulting binary, is disabled
under COMPILE_TEST, and is not enabled on any builds I'm aware of.
Additionally, given the clarified purpose of GCC plugins in the kernel,
remove cyc_complexity.
Cc: Masahiro Yamada <masahiroy@kernel.org>
Cc: Michal Marek <redacted>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: linux-hardening@vger.kernel.org
Cc: linux-kbuild@vger.kernel.org
Cc: linux-doc@vger.kernel.org
Signed-off-by: Kees Cook <redacted>
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
One comment below.
@@ -96,7 +96,6 @@ Enable the GCC plugin infrastructure and some plugin(s) you want to use in the kernel config:: CONFIG_GCC_PLUGINS=y- CONFIG_GCC_PLUGIN_CYC_COMPLEXITY=y CONFIG_GCC_PLUGIN_LATENT_ENTROPY=y ...
There is a comment about the cyc_complexity plugin at the very end of
this file that should also be removed it seems:
"See the cyc_complexity_plugin.c (CONFIG_GCC_PLUGIN_CYC_COMPLEXITY) GCC plugin."
Yup; I think it was hiding from you, see here:
quoted
@@ -115,4 +114,3 @@ The GCC plugins are in scripts/gcc-plugins/. You need to put plugin source files right under scripts/gcc-plugins/. Creating subdirectories is not supported. It must be added to scripts/gcc-plugins/Makefile, scripts/Makefile.gcc-plugins and a relevant Kconfig file.-See the cyc_complexity_plugin.c (CONFIG_GCC_PLUGIN_CYC_COMPLEXITY) GCC plugin.
On Wed, Oct 20, 2021 at 10:45:43AM -0700, Nathan Chancellor wrote:
On Wed, Oct 20, 2021 at 10:35:53AM -0700, Kees Cook wrote:
quoted
GCC plugins should only exist when some compiler feature needs to be
proven but does not exist in either GCC nor Clang. For example, if a
desired feature is already in Clang, it should be added to GCC upstream.
Document this explicitly.
Additionally, mark the plugins with matching upstream GCC features as
removable past their respective GCC versions.
Cc: Masahiro Yamada <masahiroy@kernel.org>
Cc: Michal Marek <redacted>
Cc: Nick Desaulniers <ndesaulniers@google.com>
Cc: Jonathan Corbet <corbet@lwn.net>
Cc: James Morris <jmorris@namei.org>
Cc: "Serge E. Hallyn" <serge@hallyn.com>
Cc: Nathan Chancellor <nathan@kernel.org>
Cc: linux-hardening@vger.kernel.org
Cc: linux-kbuild@vger.kernel.org
Cc: linux-doc@vger.kernel.org
Cc: linux-security-module@vger.kernel.org
Cc: llvm@lists.linux.dev
Signed-off-by: Kees Cook <redacted>
Seems reasonable to me.
Reviewed-by: Nathan Chancellor <nathan@kernel.org>
@@ -32,6 +32,32 @@ This infrastructure was ported from grsecurity [6]_ and PaX [7]_...[7] https://pax.grsecurity.net/+Purpose+=======++GCC plugins are designed to provide a place to experiment with potential+compiler features that are neither in GCC nor Clang upstream. Once+their utility is proven, the goal is to upstream the feature into GCC+(and Clang), and then to finally remove them from the kernel once the+feature is available in all supported versions of GCC.++Specifically, new plugins should implement only features that have no+upstream compiler support (in either GCC or Clang).++When a feature exists in Clang but not GCC, effort should be made to+bring the feature to upstream GCC (rather than just as a kernel-specific+GCC plugin), so the entire ecosystem can benefit from it.++Similarly, even if a feature provided by a GCC plugin does *not* exist+in Clang, but the feature is proven to be useful, effort should be spent+to upstream the feature to GCC (and Clang).++After a feature is available in upstream GCC, the plugin will be made+unbuildable for the corresponding GCC version (and later). Once all+kernel-supported versions of GCC provide the feature, the plugin will+be removed from the kernel.++ Files =====
@@ -37,6 +37,8 @@ config GCC_PLUGIN_CYC_COMPLEXITYconfigGCC_PLUGIN_SANCOVbool+# Plugin can be removed once the kernel only supports GCC 6.1.0++depends on!CC_HAS_SANCOV_TRACE_PC
This symbol is not user selectable and the one place that does select it
only does so when !CC_HAS_SANCOV_TRACE_PC so this seems pointless to me.
Keep the comment, ditch the depends?
I had a similar thought, and in the end, I decided I wanted to always
enforce the GCC feature check through a depends, with a comment about
the expected version. I want to make sure we don't use plugins if an
upstream feature is already available. It happens that SANCOV was
effectively the first to do this, but it did so on the other side and I
wanted it repeated here so it was "self contained".
-Kees
--
Kees Cook
On Wed, 20 Oct 2021 at 19:35, Kees Cook [off-list ref] wrote:
Hi,
GCC plugins should only exist when some compiler feature needs to be
proven but does not exist in either GCC nor Clang. For example, if a
desired feature is already in Clang, it should be added to GCC upstream.
Document this explicitly.
I'll put this in -next unless there are objections. :)
Thanks!
-Kees
Kees Cook (2):
gcc-plugins: Explicitly document purpose and deprecation schedule
gcc-plugins: Remove cyc_complexity