Re: [PATCH v2] kstack_erase: suppress -grecord-gcc-switches for external module builds

[Nathan Chancellor]

Hi Jaihind,

On Sun, Aug 16, 2026 at 08:11:01AM +0000, Jaihind Yadav wrote:
>   Would it be acceptable to handle this generically for external modules in
>   top-level kbuild (`Makefile`) instead of tying it to kstack_erase? I was
>   thinking about adding:
> 
>     diff --git a/Makefile b/Makefile
>     @@ -1057,6 +1057,10 @@ include $(addprefix $(srctree)/, $(include-y))
>      # Do not add $(call cc-option,...) below this line. When you build the kernel
>      # from the clean source tree, the GCC plugins do not exist at this point.
> 
>     +ifneq ($(KBUILD_EXTMOD),)
>     +KBUILD_CFLAGS += -gno-record-gcc-switches
>     +endif
>     +
>      # Add user supplied CPPFLAGS, AFLAGS, CFLAGS and RUSTFLAGS as the last assignments
> 
>   This would avoid per-module changes and also avoid coupling a generic
>   compiler switch-recording behavior to `CONFIG_GCC_PLUGIN_STACKLEAK`.
> 
>   If this direction looks reasonable, I can send it as an RFC patch for review.

I do find this direction to get more at the heart of the problem but
shouldn't this live in scripts/Makefile.gcc-plugins?

diff --git a/scripts/Makefile.gcc-plugins b/scripts/Makefile.gcc-plugins
index b0e1423b09c2..9b9899580571 100644
--- a/scripts/Makefile.gcc-plugins
+++ b/scripts/Makefile.gcc-plugins
@@ -8,6 +8,10 @@ ifdef CONFIG_GCC_PLUGIN_LATENT_ENTROPY
 endif
 export DISABLE_LATENT_ENTROPY_PLUGIN
 
+# Disable recording GCC options in debug info when building external modules to
+# avoid leaking absolute host build paths
+gcc-plugin-cflags-$(if $(KBUILD_EXTMOD),y) += -gno-record-gcc-switches
+
 # All the plugin CFLAGS are collected here in case a build target needs to
 # filter them out of the KBUILD_CFLAGS.
 GCC_PLUGINS_CFLAGS := $(strip $(addprefix -fplugin=$(objtree)/scripts/gcc-plugins/, $(gcc-plugin-y)) $(gcc-plugin-cflags-y)) -DGCC_PLUGINS
--

Otherwise, this would apply to every external module build, not just
ones that enable GCC plugins.

I defer to Kees on whether this is actually acceptable though.

-- 
Cheers,
Nathan