| 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.
On Tue, Apr 8, 2025, at 00:02, Mark Brown wrote: > 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). Talos also uses stackleak. I also see that alpine and qubes have the same two gcc plugins enabled. On the other hand none of the other 60 distros on that list use any plugins, and most of those kernels appear to be built with a compiler that doesn't support plugins. A few notable ones (Arch, Fedora CoreOS 35, RHEL 9) in the list have CONFIG_GCC_PLUGINS=y but then don't enable any of them. > 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. I've drafted patches to remove these three now: even if we're only moving from gcc-5 to gcc-8 as the minimum supported version, I don't think there is much intersection between users of those plugins and those that are stuck on gcc-11 or earlier. Arnd
On April 8, 2025 2:22:52 AM PDT, Arnd Bergmann <arnd@arndb.de> wrote: >On Tue, Apr 8, 2025, at 00:02, Mark Brown wrote: >> 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). The early RNG for small machines remains pretty bad, so I can understand wanting to keep that around. For bigger machines it's not as much of a benefit. >Talos also uses stackleak. I also see that alpine and qubes have the >same two gcc plugins enabled. Yeah, stackleak has no viable alternative. It's effectively init_on_free for stack. It's be nice if there were a way to do this with upstream compilers (track call depth). >On the other hand none of the other 60 distros on that list use any >plugins, and most of those kernels appear to be built with a compiler >that doesn't support plugins. A few notable ones (Arch, Fedora >CoreOS 35, RHEL 9) in the list have CONFIG_GCC_PLUGINS=y but then >don't enable any of them. > >> 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. > >I've drafted patches to remove these three now: even if we're >only moving from gcc-5 to gcc-8 as the minimum supported version, >I don't think there is much intersection between users of those >plugins and those that are stuck on gcc-11 or earlier. I have no problem removing sanconv (no longer needed), structleak (zero-init is more complete), and stackprot-tls (assuming it really is supported after GCC 12?) -Kees
On Mon, Apr 07, 2025 at 09:57:32PM +0100, Mark Brown wrote: > 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. Looks like this is a randstruct bug. We'll need to disable that one for now (rather than all plugins). I can reproduce this for GCC 14, but I can't reproduce this with GCC 13. Which minor release is failing for you? My GCC 13 is: gcc (Ubuntu 13.3.0-6ubuntu2~24.04) 13.3.0 -Kees
On Wed, Apr 9, 2025, at 01:32, Kees Cook wrote: > I can reproduce this for GCC 14, but I can't reproduce this with GCC > 13. Which minor release is failing for you? My GCC 13 is: > gcc (Ubuntu 13.3.0-6ubuntu2~24.04) 13.3.0 I see it with "x86_64-linux-gnu-gcc-12 (Debian 12.2.0-14) 12.2.0" (cross-compiling from arm64). Arnd
On Tue, Apr 08, 2025 at 04:32:24PM -0700, Kees Cook wrote: > On Mon, Apr 07, 2025 at 09:57:32PM +0100, Mark Brown 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. > Looks like this is a randstruct bug. We'll need to disable that one for > now (rather than all plugins). Note that the patch is only disabling for build coverage builds where the resulting binaries generally aren't going to actually be run. > I can reproduce this for GCC 14, but I can't reproduce this with GCC > 13. Which minor release is failing for you? My GCC 13 is: > gcc (Ubuntu 13.3.0-6ubuntu2~24.04) 13.3.0 Should have been x86_64-linux-gnu-gcc (Debian 13.3.0-5) 13.3.0.
On Wed, 9 Apr 2025 at 05:20, Mark Brown <broonie@kernel.org> wrote: > > Note that the patch is only disabling for build coverage builds where > the resulting binaries generally aren't going to actually be run. Well, there's a reason we do build coverage - we also want to test that the non-build coverage case builds. And it's not actually obvious that it does - it's in fact rather likely that the gcc plugin is broken in general, and it just so happens that it's the build bots that find it. Which is why I honestly would prefer to just disable the plugins in general. Because the problem is the plugin, not the build coverage. Linus
On Wed, Apr 09, 2025 at 08:33:03AM -0700, Linus Torvalds wrote: > On Wed, 9 Apr 2025 at 05:20, Mark Brown <broonie@kernel.org> wrote: > > Note that the patch is only disabling for build coverage builds where > > the resulting binaries generally aren't going to actually be run. > Well, there's a reason we do build coverage - we also want to test > that the non-build coverage case builds. > And it's not actually obvious that it does - it's in fact rather > likely that the gcc plugin is broken in general, and it just so > happens that it's the build bots that find it. Sadly it seems like the build bots didn't find it, or at least if they found it they didn't identify it well enough to end up with reporting the issue to someone who'd fix it. I ran into it because I do allmodconfig builds as part of applying things since both you and Stephen do them and that exploded in my face at -rc1. > Which is why I honestly would prefer to just disable the plugins in general. > Because the problem is the plugin, not the build coverage. Well, yes.
On Wed, 9 Apr 2025 at 10:29, Mark Brown <broonie@kernel.org> wrote: > > Sadly it seems like the build bots didn't find it, or at least if they > found it they didn't identify it well enough to end up with reporting > the issue to someone who'd fix it. I wouldn't be entirely surpised if a lot of the build bots end up running old distros (because "enterprise"). So this is presumably only happening with certain compiler versions, and I expect the build bots have a fairly small set of compilers they end up testing. Linus
On Wed, Apr 09, 2025 at 10:42:19AM -0700, Linus Torvalds wrote: > On Wed, 9 Apr 2025 at 10:29, Mark Brown <broonie@kernel.org> wrote: > > > > Sadly it seems like the build bots didn't find it, or at least if they > > found it they didn't identify it well enough to end up with reporting > > the issue to someone who'd fix it. > > I wouldn't be entirely surpised if a lot of the build bots end up > running old distros (because "enterprise"). > > So this is presumably only happening with certain compiler versions, > and I expect the build bots have a fairly small set of compilers they > end up testing. I'm still trying to figure out what the matrix is, because I can reproduce the crash on Debian's GCC 12 but not Ubuntu's GCC 13, etc. It feels like there are a few corner cases involved here. So it's not just the regular "new compiler changes" that usually break the plugins. Regardless, I'm still digging...
On Wed, Apr 09, 2025 at 10:42:19AM -0700, Linus Torvalds wrote: > On Wed, 9 Apr 2025 at 10:29, Mark Brown <broonie@kernel.org> wrote: > > Sadly it seems like the build bots didn't find it, or at least if they > > found it they didn't identify it well enough to end up with reporting > > the issue to someone who'd fix it. > I wouldn't be entirely surpised if a lot of the build bots end up > running old distros (because "enterprise"). I know bunch of them are running Debian, often with a default GCC of whatever the base Debian version they're running has at any given time. > So this is presumably only happening with certain compiler versions, > and I expect the build bots have a fairly small set of compilers they > end up testing. Yeah. The other problem we have is that AFAIK unlike clang we don't really have people actively working on GCC coverage specifically, everyone mostly just assumes everyone else is doing it since GCC is the default (me being as guilty of that as everyone else here). The work Arnd's doing is the nearest thing I'm aware of but that's more intermittent and I gather his toolchains don't have plugins enabled which wouldn't help here.
On Wed, Apr 9, 2025, at 20:09, Mark Brown wrote: > On Wed, Apr 09, 2025 at 10:42:19AM -0700, Linus Torvalds wrote: > > Yeah. The other problem we have is that AFAIK unlike clang we don't > really have people actively working on GCC coverage specifically, > everyone mostly just assumes everyone else is doing it since GCC is the > default (me being as guilty of that as everyone else here). The work > Arnd's doing is the nearest thing I'm aware of but that's more > intermittent and I gather his toolchains don't have plugins enabled > which wouldn't help here. Right, I don't think there is any sensible way to support plugins with my cross compilers, because that requires building the plugin on a developer's machine and link it against the compiler I statically linked against a specific libstdc++ to avoid runtime compatibility problems. Arnd
On Tue, Apr 8, 2025, at 22:37, Kees Cook wrote: > On April 8, 2025 2:22:52 AM PDT, Arnd Bergmann <arnd@arndb.de> wrote: >>> >>> indicates that Talos 1.9.1 uses latent_entropy (but we didn't check how >>> accurate that survey is). > > The early RNG for small machines remains pretty bad, so I can > understand wanting to keep that around. For bigger machines it's not as > much of a benefit. Does "small machines" still mean those without a cycle counter as in the 2009 article [https://phrack.org/issues/66/15#article] or are you thinking of those that may have a working random_get_entropy() but that remains too predictable for add_device_randomness() because of the low frequency (e.g. 19.2 MHz on many ARMv7/v8)? The former (ARMv5, AMD Elan, Xburst) were still common back then but are mostly extinct now, while the latter obviously remain in wide use. >>Talos also uses stackleak. I also see that alpine and qubes have the >>same two gcc plugins enabled. > > Yeah, stackleak has no viable alternative. It's effectively > init_on_free for stack. It's be nice if there were a way to do this > with upstream compilers (track call depth). I guess a simplified version could in theory be done in the kernel using _mcount without compiler help, but that would be much more expensive if every function entry has to call it, right? Arnd
On Mon, 07 Apr 2025 13:57:32 PDT (-0700), broonie@kernel.org wrote: > 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(+) > > 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) > > --- > base-commit: 0af2f6be1b4281385b618cb86ad946eded089ac8 > change-id: 20250407-kbuild-disable-gcc-plugins-8701aa609cb3 > > Best regards, This one's been biting me too. It manifests for me on gcc-12 and gcc-13 (both locally built toolchains off the release branches, cross compiling for RISC-V). Tested-by: Palmer Dabbelt <palmer@rivosinc.com>
On Tue, Apr 15, 2025 at 01:26:34PM -0700, Palmer Dabbelt wrote: > On Mon, 07 Apr 2025 13:57:32 PDT (-0700), broonie@kernel.org wrote: > > 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: > This one's been biting me too. It manifests for me on gcc-12 and gcc-13 > (both locally built toolchains off the release branches, cross compiling for > RISC-V). > Tested-by: Palmer Dabbelt <palmer@rivosinc.com> Kees has a narrower workaround for this: https://lore.kernel.org/all/20250409151154.work.872-kees@kernel.org/ It's in -next but not pending-fixes, I'm not sure what the plan is for getting this into mainline - Kees? The commit log mentions getting it in for -rc2 so I think the plan is to merge it as a fix.
On Tue, Apr 15, 2025 at 01:26:34PM -0700, Palmer Dabbelt wrote: > On Mon, 07 Apr 2025 13:57:32 PDT (-0700), broonie@kernel.org wrote: > > 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(+) > > > > 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) > > > > --- > > base-commit: 0af2f6be1b4281385b618cb86ad946eded089ac8 > > change-id: 20250407-kbuild-disable-gcc-plugins-8701aa609cb3 > > > > Best regards, > > This one's been biting me too. It manifests for me on gcc-12 and gcc-13 > (both locally built toolchains off the release branches, cross compiling for > RISC-V). > > Tested-by: Palmer Dabbelt <palmer@rivosinc.com> Thanks! This is fixed differently in -next: https://web.git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/commit/?h=for-linus/hardening&id=1ded828affa35f4b216e99f53d8d031a392f2b0a
On Tue, Apr 15, 2025 at 09:41:06PM +0100, Mark Brown wrote: > On Tue, Apr 15, 2025 at 01:26:34PM -0700, Palmer Dabbelt wrote: > > On Mon, 07 Apr 2025 13:57:32 PDT (-0700), broonie@kernel.org wrote: > > > > 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: > > > This one's been biting me too. It manifests for me on gcc-12 and gcc-13 > > (both locally built toolchains off the release branches, cross compiling for > > RISC-V). > > > Tested-by: Palmer Dabbelt <palmer@rivosinc.com> > > Kees has a narrower workaround for this: > > https://lore.kernel.org/all/20250409151154.work.872-kees@kernel.org/ > > It's in -next but not pending-fixes, I'm not sure what the plan is for > getting this into mainline - Kees? The commit log mentions getting it > in for -rc2 so I think the plan is to merge it as a fix. Yeah, I missed -rc2, and will send it to Linus for -rc3 (with other stuff) probably tomorrow.
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,