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

[ Please reply interleaved,
  cp.  Documentation/process/submitting-patches.rst ]

On Fri, Aug 14, 2026 at 08:27:58AM +0000, Jaihind Yadav wrote:

Hi Kees,

  That's a fair point.

  In my testing, the issue was observed specifically with the STACKLEAK
  plugin path being recorded in DWARF producer strings for KBUILD_EXTMOD
  builds via:

    -fplugin=$(objtree)/scripts/gcc-plugins/stackleak_plugin.so

  The motivation for this patch was to address that specific issue with
  the smallest possible change.

  I agree the same behavior may apply to other GCC plugins when their
  -fplugin arguments contain build-specific absolute paths. A more general
  solution may make sense, but I wasn't sure whether disabling recorded
  GCC switches more broadly would be desirable from a debugging
  information perspective.

[...]

On Thu, Aug 13, 2026 at 01:59:49PM +0530, Jaihind Yadav wrote:

quoted

With CONFIG_GCC_PLUGIN_STACKLEAK=y, kstack erase adds:

  -fplugin=$(objtree)/scripts/gcc-plugins/stackleak_plugin.so

For KBUILD_EXTMOD builds, recording gcc switches can embed this 
host/build specific plugin path into module DWARF producer strings, 
which trips QA checks looking for absolute path leakage.

Isn't this a problem for all Linux gcc plugins, though?

-Kees

quoted

Disable gcc switch recording only for external modules by adding 
-gno-record-gcc-switches to kstack-erase-cflags when KBUILD_EXTMOD is set.

This keeps stackleak plugin instrumentation enabled while avoiding 
leakage of host-specific paths in external module debug metadata.

Suggested-by: Nathan Chancellor <nathan@kernel.org>
Link: https://lore.kernel.org/all/20260803181217.GB1067866@ax162/ (local)
Signed-off-by: Jaihind Yadav <redacted>
---
 scripts/Makefile.kstack_erase | 1 +
 1 file changed, 1 insertion(+)

diff --git a/scripts/Makefile.kstack_erase b/scripts/Makefile.kstack_erase
index ee7e4ef7b892..6f31a3915d24 100644
--- a/scripts/Makefile.kstack_erase
+++ b/scripts/Makefile.kstack_erase

@@ -5,6 +5,7 @@ kstack-erase-cflags-y += -fplugin=$(objtree)/scripts/gcc-plugins/stackleak_plugi
 kstack-erase-cflags-y += -fplugin-arg-stackleak_plugin-track-min-size=$(CONFIG_KSTACK_ERASE_TRACK_MIN_SIZE)
 kstack-erase-cflags-y += -fplugin-arg-stackleak_plugin-arch=$(SRCARCH)
 kstack-erase-cflags-$(CONFIG_GCC_PLUGIN_STACKLEAK_VERBOSE) += -fplugin-arg-stackleak_plugin-verbose
+kstack-erase-cflags-$(if $(KBUILD_EXTMOD),y) += -gno-record-gcc-switches

As -gno-record-gcc-switches is not specific to kstack-erase, I am not
convinced that CONFIG_GCC_PLUGIN_STACKLEAK is a good switch for it.
Might it be that someone has CONFIG_GCC_PLUGIN_STACKLEAK enabled but
wants (some other) gcc switches to be recorded?


If there is a need for external kmods to to have 

  make modules KCFLAGS=-gno-record-gcc-switches

automated in kbuild, I'd rather like to see a new Kconfig symbol for
that flag (some CONFIG_EXT_MOD_NO_RECORD_GCC_SWITCHES) but a Kconfig
symbol only for external kmods feels odd to me, too.

HTH.

Kind regards,
Nicolas