Message ID | 20250407-kbuild-disable-gcc-plugins-v1-1-5d46ae583f5e@kernel.org (mailing list archive) |
---|---|
State | New |
Headers | show |
Series | gcc-plugins: Disable GCC plugins for compile test builds | expand |
On Mon, 7 Apr 2025 at 14:10, Mark Brown <broonie@kernel.org> wrote: > > Arnd bisected this to c56f649646ec ("landlock: Log mount-related > denials") but that commit is fairly obviously not really at fault here, > most likely this is an issue in the plugin. Given how disruptive having > key configs like this failing let's disable the plugins for compile test > builds until a fix is found. I'm not against this, but I do want to bring up the "are the plugins worth having at all" discussion again. They've been a pain before. Afaik, the actual useful cases are now done by actual real compiler support (and by clang, at that). Who actually *uses* the gcc plugins? They just worry me in general, and this is not the first time they have caused ICE problems. Linus
On Mon, Apr 07, 2025 at 02:33:40PM -0700, Linus Torvalds wrote: > On Mon, 7 Apr 2025 at 14:10, Mark Brown <broonie@kernel.org> wrote: > > Arnd bisected this to c56f649646ec ("landlock: Log mount-related > > denials") but that commit is fairly obviously not really at fault here, > > most likely this is an issue in the plugin. Given how disruptive having > > key configs like this failing let's disable the plugins for compile test > > builds until a fix is found. > I'm not against this, but I do want to bring up the "are the plugins > worth having at all" discussion again. > They've been a pain before. Afaik, the actual useful cases are now > done by actual real compiler support (and by clang, at that). > Who actually *uses* the gcc plugins? They just worry me in general, > and this is not the first time they have caused ICE problems. There was a bit of discussion of that on IRC which didn't summon up huge enthusiasm for them. Arnd noted that: https://github.com/nyrahul/linux-kernel-configs indicates that Talos 1.9.1 uses latent_entropy (but we didn't check how accurate that survey is). He also noted that GCC_PLUGIN_SANCOV is obsolete as of GCC 6 (!) and both CC_HAVE_STACKPROTECTOR_TLS and GCC_PLUGIN_STRUCTLEAK_BYREF_ALL as of GCC 12, Ard indicated he wasn't worried about loosing CC_HAVE_STACKPROTECTOR_TLS.
diff --git a/scripts/gcc-plugins/Kconfig b/scripts/gcc-plugins/Kconfig index e383cda05367..29b03c136165 100644 --- a/scripts/gcc-plugins/Kconfig +++ b/scripts/gcc-plugins/Kconfig @@ -7,6 +7,7 @@ config HAVE_GCC_PLUGINS menuconfig GCC_PLUGINS bool "GCC plugins" + depends on !COMPILE_TEST depends on HAVE_GCC_PLUGINS depends on CC_IS_GCC depends on $(success,test -e $(shell,$(CC) -print-file-name=plugin)/include/plugin-version.h)
In current mainline x86_64 allmodconfig builds done with tuxmake GCC 13 and GCC 14 toolchains (which are Debian ones packaged up into containers) generate ICEs in landlock: Event | Plugins PLUGIN_FINISH_TYPE | randomize_layout_plugin PLUGIN_FINISH_DECL | randomize_layout_plugin PLUGIN_ATTRIBUTES | latent_entropy_plugin randomize_layout_plugin PLUGIN_START_UNIT | latent_entropy_plugin stackleak_plugin PLUGIN_ALL_IPA_PASSES_START | randomize_layout_plugin /build/stage/linux/security/landlock/fs.c: In function ‘hook_file_ioctl_common’: /build/stage/linux/security/landlock/fs.c:1745:61: internal compiler error: in c ount_type_elements, at expr.cc:7075 1745 | .u.op = &(struct lsm_ioctlop_audit) { | ^ Arnd bisected this to c56f649646ec ("landlock: Log mount-related denials") but that commit is fairly obviously not really at fault here, most likely this is an issue in the plugin. Given how disruptive having key configs like this failing let's disable the plugins for compile test builds until a fix is found. Suggested-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Mark Brown <broonie@kernel.org> --- scripts/gcc-plugins/Kconfig | 1 + 1 file changed, 1 insertion(+) --- base-commit: 0af2f6be1b4281385b618cb86ad946eded089ac8 change-id: 20250407-kbuild-disable-gcc-plugins-8701aa609cb3 Best regards,