[ 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: > > 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 > > > > > 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 <[email protected]> > > Link: https://lore.kernel.org/all/20260803181217.GB1067866@ax162/ > > Signed-off-by: Jaihind Yadav <[email protected]> > > --- > > 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
