Re: [PATCH 1/1] scripts: kstack_erase: use relative stackleak plugin path

[Nathan Chancellor]

On Wed, Aug 12, 2026 at 10:55:38AM +0000, Jaihind Yadav wrote:
> Hi Nathan And Nicolas ,
> 
> Thanks for the feedback.
> 
> I took another look at this and experimented with a different approach for external modules:
> 
> diff --git a/scripts/Makefile.kstack_erase b/scripts/Makefile.kstack_erase
> index ee7e4ef7b892..xxxxxxxxxxxx 100644
> --- a/scripts/Makefile.kstack_erase
> +++ b/scripts/Makefile.kstack_erase
> @@ -5,6 +5,10 @@ kstack-erase-cflags-y += -fplugin=$(objtree)/scripts/gcc-plugins/stackleak_plugin.so
>  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
> +ifneq ($(KBUILD_EXTMOD),)
> +# Avoid embedding absolute -fplugin paths into external module DWARF metadata.
> +kstack-erase-cflags-y += -gno-record-gcc-switches
> +endif
>  DISABLE_KSTACK_ERASE := -fplugin-arg-stackleak_plugin-disable
>  endif
> 
> In my testing, this prevents the absolute stackleak plugin path specified via
> 
>     -fplugin=$(objtree)/scripts/gcc-plugins/stackleak_plugin.so
> 
> from being recorded in the DWARF information of out-of-tree modules, while avoiding the use of platform-specific utilities such as realpath/readlink --relative-to.
> 
> I agree this does not solve the broader issue for all GCC plugins, but it appears to address the specific KSTACK_ERASE case that originally motivated the discussion.
> 
> Would this direction be more acceptable than the previous relative-path approach, or would suppressing GCC switch recording for external modules be considered undesirable from a debugging-information perspective?

This seems more reasonable to me. You could save a couple of lines by
making it

  kstack-erase-cflags-$(if $(KBUILD_EXTMOD),y) += -gno-record-gcc-switches

but I guess that is personal style. I doubt it would hamper debugging to
have this done unconditionally but we could always revisit it if someone
complains.

-- 
Cheers,
Nathan