[PATCH 0/1] scripts: kstack_erase: avoid absolute stackleak plugin path

[PATCH 0/1] scripts: kstack_erase: avoid absolute stackleak plugin path

[Jaihind Yadav]

Use a relative -fplugin path for CONFIG_KSTACK_ERASE stackleak plugin
invocation to avoid embedding absolute build paths in recorded compiler
switch metadata.

Jaihind Yadav (1):
  scripts: kstack_erase: use relative stackleak plugin path

 scripts/Makefile.kstack_erase | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

-- 
2.43.0

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

[Jaihind Yadav]

GCC records full compiler command lines in DWARF producer strings by\ndefault. With CONFIG_KSTACK_ERASE, the stackleak plugin is currently\npassed using an absolute -fplugin path, which can leak host-specific\nbuild paths into debug artifacts.\n\nResolve the stackleak plugin directory relative to the current build\ndirectory and use that in the -fplugin option, falling back to the\nexisting absolute objtree path when needed.\n\nThis keeps plugin loading behavior unchanged while avoiding absolute\nworkspace paths in recorded compiler flags.

Signed-off-by: Jaihind Yadav <jaihindy@qti.qualcomm.com>
---
 scripts/Makefile.kstack_erase | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/scripts/Makefile.kstack_erase b/scripts/Makefile.kstack_erase
index ee7e4ef7b8926..006d10f3b77a0 100644
--- a/scripts/Makefile.kstack_erase
+++ b/scripts/Makefile.kstack_erase
@@ -1,7 +1,10 @@
 # SPDX-License-Identifier: GPL-2.0
 
 ifdef CONFIG_GCC_PLUGIN_STACKLEAK
-kstack-erase-cflags-y += -fplugin=$(objtree)/scripts/gcc-plugins/stackleak_plugin.so
+stackleak-plugin-dir := $(or \
+	$(shell realpath -m --relative-to=$(CURDIR) $(objtree)/scripts/gcc-plugins 2>/dev/null), \
+	$(objtree)/scripts/gcc-plugins)
+kstack-erase-cflags-y += -fplugin=$(stackleak-plugin-dir)/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
-- 
2.43.0

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

[Nicolas Schier]

[-- Attachment #1: Type: text/plain, Size: 2180 bytes --]

Hi Jaihind,

On Mon, Jul 20, 2026 at 03:05:45PM +0530, Jaihind Yadav wrote:
> GCC records full compiler command lines in DWARF producer strings by\ndefault. With CONFIG_KSTACK_ERASE, the stackleak plugin is currently\npassed using an absolute -fplugin path, which can leak host-specific\nbuild paths into debug artifacts.\n\nResolve the stackleak plugin directory relative to the current build\ndirectory and use that in the -fplugin option, falling back to the\nexisting absolute objtree path when needed.\n\nThis keeps plugin loading behavior unchanged while avoiding absolute\nworkspace paths in recorded compiler flags.

Please note: while the patch below is applicable, your commit message is 
broken ("\n" instead of newlines).




Can you give me a hint on how to reproduce the described behaviour?
I enabled

CONFIG_DEBUG_INFO=y
CONFIG_DEBUG_INFO_DWARF5=y
CONFIG_KSTACK_ERASE=y

and built with O=build but cannot find the path to the plugin dir in any 
binary build artifact I grep'ed.  What do I have to do to find the 
plugin path there?

[...]
> diff --git a/scripts/Makefile.kstack_erase b/scripts/Makefile.kstack_erase
> index ee7e4ef7b8926..006d10f3b77a0 100644
> --- a/scripts/Makefile.kstack_erase
> +++ b/scripts/Makefile.kstack_erase
> @@ -1,7 +1,10 @@
>  # SPDX-License-Identifier: GPL-2.0
>  
>  ifdef CONFIG_GCC_PLUGIN_STACKLEAK
> -kstack-erase-cflags-y += -fplugin=$(objtree)/scripts/gcc-plugins/stackleak_plugin.so
> +stackleak-plugin-dir := $(or \
> +	$(shell realpath -m --relative-to=$(CURDIR) $(objtree)/scripts/gcc-plugins 2>/dev/null), \
> +	$(objtree)/scripts/gcc-plugins)
> +kstack-erase-cflags-y += -fplugin=$(stackleak-plugin-dir)/stackleak_plugin.so

As Kbuild changes the working directory to KBUILD_OUTPUT build dir for 
compilation, I'd assume that '$(objtree)/' should just be removed and 
scripts/gcc-plugins/stackleak_plugin.so be the always matching relative 
path to the plugin:

-kstack-erase-cflags-y += -fplugin=$(objtree)/scripts/gcc-plugins/stackleak_plugin.so
+kstack-erase-cflags-y += -fplugin=scripts/gcc-plugins/stackleak_plugin.so

Does that work for you?

Kind regards,
Nicolas

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Jaihind Yadav]

Hi Nicolas Schier,

Thanks for looking into this and for the suggestion.

The issue is only observable when building out-of-tree kernel modules with CONFIG_KSTACK_ERASE=y enabled. I did not notice the problem for in-tree kernel objects.

As an example, in our setup msm_kgsl.ko is built as an out-of-tree module. The absolute path to the stackleak plugin gets embedded into the DWARF producer string and consequently appears in the generated module:

readelf --debug-dump=info \
./tmp/work/<machine_name>-qcom-linux/kgsl-dlkm/0.0+git/image/usr/lib/modules/6.18.0-rc6-00263-g3d5db6797b5f/updates/msm_kgsl.ko \
| grep fplugin | tail

Output:
DW_AT_producer : GNU C11 15.2.0 ... \
-fplugin=/local/mnt/workspace/abhi/QLI-MAINLINE/build/tmp/work-shared/target-ride-sx/kernel-build-artifacts/scripts/gcc-plugins/stackleak_plugin.so \
-fplugin-arg-stackleak_plugin-track-min-size=100 ...


As can be seen above, the full build path to stackleak_plugin.so is recorded in the DWARF metadata of the out-of-tree module.

I have not yet tried your proposed simplification:

-kstack-erase-cflags-y += -fplugin=$(objtree)/scripts/gcc-plugins/stackleak_plugin.so
+kstack-erase-cflags-y += -fplugin=scripts/gcc-plugins/stackleak_plugin.so


At first glance it does seem reasonable given that Kbuild changes the working directory to KBUILD_OUTPUT during compilation. Please Let me try this approach with the out-of-tree module build and I'll report back with the results.

Thanks again for the suggestion.

Thanks &  Regards,
Jaihind Yadav


-----Original Message-----
From: Nicolas Schier <n.schier@fritz.com> 
Sent: Wednesday, July 22, 2026 8:16 PM
To: Jaihind Yadav <jaihindy@qti.qualcomm.com>
Cc: nathan@kernel.org; kees@kernel.org; linux-kbuild@vger.kernel.org; linux-hardening@vger.kernel.org; gustavoars@kernel.org; linux-kernel@vger.kernel.org; nsc@kernel.org
Subject: Re: [PATCH 1/1] scripts: kstack_erase: use relative stackleak plugin path

Hi Jaihind,

On Mon, Jul 20, 2026 at 03:05:45PM +0530, Jaihind Yadav wrote:
> GCC records full compiler command lines in DWARF producer strings by\ndefault. With CONFIG_KSTACK_ERASE, the stackleak plugin is currently\npassed using an absolute -fplugin path, which can leak host-specific\nbuild paths into debug artifacts.\n\nResolve the stackleak plugin directory relative to the current build\ndirectory and use that in the -fplugin option, falling back to the\nexisting absolute objtree path when needed.\n\nThis keeps plugin loading behavior unchanged while avoiding absolute\nworkspace paths in recorded compiler flags.

Please note: while the patch below is applicable, your commit message is broken ("\n" instead of newlines).




Can you give me a hint on how to reproduce the described behaviour?
I enabled

CONFIG_DEBUG_INFO=y
CONFIG_DEBUG_INFO_DWARF5=y
CONFIG_KSTACK_ERASE=y

and built with O=build but cannot find the path to the plugin dir in any 
binary build artifact I grep'ed.  What do I have to do to find the 
plugin path there?

[...]
> diff --git a/scripts/Makefile.kstack_erase b/scripts/Makefile.kstack_erase
> index ee7e4ef7b8926..006d10f3b77a0 100644
> --- a/scripts/Makefile.kstack_erase
> +++ b/scripts/Makefile.kstack_erase
> @@ -1,7 +1,10 @@
>  # SPDX-License-Identifier: GPL-2.0
>  
>  ifdef CONFIG_GCC_PLUGIN_STACKLEAK
> -kstack-erase-cflags-y += -fplugin=$(objtree)/scripts/gcc-plugins/stackleak_plugin.so
> +stackleak-plugin-dir := $(or \
> +	$(shell realpath -m --relative-to=$(CURDIR) $(objtree)/scripts/gcc-plugins 2>/dev/null), \
> +	$(objtree)/scripts/gcc-plugins)
> +kstack-erase-cflags-y += -fplugin=$(stackleak-plugin-dir)/stackleak_plugin.so

As Kbuild changes the working directory to KBUILD_OUTPUT build dir for 
compilation, I'd assume that '$(objtree)/' should just be removed and 
scripts/gcc-plugins/stackleak_plugin.so be the always matching relative 
path to the plugin:

-kstack-erase-cflags-y += -fplugin=$(objtree)/scripts/gcc-plugins/stackleak_plugin.so
+kstack-erase-cflags-y += -fplugin=scripts/gcc-plugins/stackleak_plugin.so

Does that work for you?

Kind regards,
Nicolas

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

[Jaihind Yadav]

Hi Nicolas Schier,

Thanks for the suggestion. I tested the proposed change:

-kstack-erase-cflags-y += -fplugin=$(objtree)/scripts/gcc-plugins/stackleak_plugin.so
+kstack-erase-cflags-y += -fplugin=scripts/gcc-plugins/stackleak_plugin.so


Unfortunately, it does not work for the out-of-tree module builds in my environment.

With this change, in-tree kernel objects build successfully, but external kernel modules fail because GCC is unable to locate the plugin. For example, I see the following error when building out-of-tree modules such as qps615-dlkm, kgsl-dlkm, and camx-dlkm:

cc1: error: cannot load plugin scripts/gcc-plugins/stackleak_plugin.so:
scripts/gcc-plugins/stackleak_plugin.so: cannot open shared object file:
No such file or directory


The original issue I reported is specific to out-of-tree modules. When CONFIG_KSTACK_ERASE=y is enabled, the absolute path to stackleak_plugin.so gets recorded in the DWARF producer string. For example:

-fplugin=/local/mnt/workspace/abhi/QLI-MAINLINE/build/tmp/work-shared/target-ride-sx/kernel-build-artifacts/scripts/gcc-plugins/stackleak_plugin.so


gets embedded into the debug metadata of the generated module.

Given that the proposed relative path breaks out-of-tree module builds, could you please take a look at the patch I posted? If the approach looks reasonable, I would appreciate your review and consideration for merging it.

Thank you for your time and feedback.

Thanks and  regards,
 Jaihind Yadav

-----Original Message-----
From: Jaihind Yadav 
Sent: Wednesday, July 22, 2026 10:48 PM
To: 'Nicolas Schier' <n.schier@fritz.com>
Cc: nathan@kernel.org; kees@kernel.org; linux-kbuild@vger.kernel.org; linux-hardening@vger.kernel.org; gustavoars@kernel.org; linux-kernel@vger.kernel.org; nsc@kernel.org
Subject: RE: [PATCH 1/1] scripts: kstack_erase: use relative stackleak plugin path


Hi Nicolas Schier,

Thanks for looking into this and for the suggestion.

The issue is only observable when building out-of-tree kernel modules with CONFIG_KSTACK_ERASE=y enabled. I did not notice the problem for in-tree kernel objects.

As an example, in our setup msm_kgsl.ko is built as an out-of-tree module. The absolute path to the stackleak plugin gets embedded into the DWARF producer string and consequently appears in the generated module:

readelf --debug-dump=info \
./tmp/work/<machine_name>-qcom-linux/kgsl-dlkm/0.0+git/image/usr/lib/modules/6.18.0-rc6-00263-g3d5db6797b5f/updates/msm_kgsl.ko \
| grep fplugin | tail

Output:
DW_AT_producer : GNU C11 15.2.0 ... \
-fplugin=/local/mnt/workspace/abhi/QLI-MAINLINE/build/tmp/work-shared/target-ride-sx/kernel-build-artifacts/scripts/gcc-plugins/stackleak_plugin.so \
-fplugin-arg-stackleak_plugin-track-min-size=100 ...


As can be seen above, the full build path to stackleak_plugin.so is recorded in the DWARF metadata of the out-of-tree module.

I have not yet tried your proposed simplification:

-kstack-erase-cflags-y += -fplugin=$(objtree)/scripts/gcc-plugins/stackleak_plugin.so
+kstack-erase-cflags-y += 
+-fplugin=scripts/gcc-plugins/stackleak_plugin.so


At first glance it does seem reasonable given that Kbuild changes the working directory to KBUILD_OUTPUT during compilation. Please Let me try this approach with the out-of-tree module build and I'll report back with the results.

Thanks again for the suggestion.

Thanks &  Regards,
Jaihind Yadav


-----Original Message-----
From: Nicolas Schier <n.schier@fritz.com>
Sent: Wednesday, July 22, 2026 8:16 PM
To: Jaihind Yadav <jaihindy@qti.qualcomm.com>
Cc: nathan@kernel.org; kees@kernel.org; linux-kbuild@vger.kernel.org; linux-hardening@vger.kernel.org; gustavoars@kernel.org; linux-kernel@vger.kernel.org; nsc@kernel.org
Subject: Re: [PATCH 1/1] scripts: kstack_erase: use relative stackleak plugin path

Hi Jaihind,

On Mon, Jul 20, 2026 at 03:05:45PM +0530, Jaihind Yadav wrote:
> GCC records full compiler command lines in DWARF producer strings by\ndefault. With CONFIG_KSTACK_ERASE, the stackleak plugin is currently\npassed using an absolute -fplugin path, which can leak host-specific\nbuild paths into debug artifacts.\n\nResolve the stackleak plugin directory relative to the current build\ndirectory and use that in the -fplugin option, falling back to the\nexisting absolute objtree path when needed.\n\nThis keeps plugin loading behavior unchanged while avoiding absolute\nworkspace paths in recorded compiler flags.

Please note: while the patch below is applicable, your commit message is broken ("\n" instead of newlines).




Can you give me a hint on how to reproduce the described behaviour?
I enabled

CONFIG_DEBUG_INFO=y
CONFIG_DEBUG_INFO_DWARF5=y
CONFIG_KSTACK_ERASE=y

and built with O=build but cannot find the path to the plugin dir in any binary build artifact I grep'ed.  What do I have to do to find the plugin path there?

[...]
> diff --git a/scripts/Makefile.kstack_erase 
> b/scripts/Makefile.kstack_erase index ee7e4ef7b8926..006d10f3b77a0 
> 100644
> --- a/scripts/Makefile.kstack_erase
> +++ b/scripts/Makefile.kstack_erase
> @@ -1,7 +1,10 @@
>  # SPDX-License-Identifier: GPL-2.0
>  
>  ifdef CONFIG_GCC_PLUGIN_STACKLEAK
> -kstack-erase-cflags-y += 
> -fplugin=$(objtree)/scripts/gcc-plugins/stackleak_plugin.so
> +stackleak-plugin-dir := $(or \
> +	$(shell realpath -m --relative-to=$(CURDIR) $(objtree)/scripts/gcc-plugins 2>/dev/null), \
> +	$(objtree)/scripts/gcc-plugins)
> +kstack-erase-cflags-y += 
> +-fplugin=$(stackleak-plugin-dir)/stackleak_plugin.so

As Kbuild changes the working directory to KBUILD_OUTPUT build dir for compilation, I'd assume that '$(objtree)/' should just be removed and scripts/gcc-plugins/stackleak_plugin.so be the always matching relative path to the plugin:

-kstack-erase-cflags-y += -fplugin=$(objtree)/scripts/gcc-plugins/stackleak_plugin.so
+kstack-erase-cflags-y += 
+-fplugin=scripts/gcc-plugins/stackleak_plugin.so

Does that work for you?

Kind regards,
Nicolas

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

[Nicolas Schier]

On Wed, Jul 22, 2026 at 07:00:43PM +0000, Jaihind Yadav wrote:
> 
> Hi Nicolas Schier,
> 
> Thanks for the suggestion. I tested the proposed change:
> 
> -kstack-erase-cflags-y += -fplugin=$(objtree)/scripts/gcc-plugins/stackleak_plugin.so
> +kstack-erase-cflags-y += -fplugin=scripts/gcc-plugins/stackleak_plugin.so
> 
> 
> Unfortunately, it does not work for the out-of-tree module builds in
> my environment.

Thanks for checking; and yes I forgot out-of-tree modules.  When
building them, Kbuild changes to their respective output directory so my
suggestion had to fail for oot kmods.

[...]
> Given that the proposed relative path breaks out-of-tree module
> builds, could you please take a look at the patch I posted? If the
> approach looks reasonable, I would appreciate your review and
> consideration for merging it.

I am not sure, if we can take your path, as 'readlink --relative-to' is
only available in coreutils/Linux but coreutils are not a documented
requirement for Linux builds (cp. Documentation/process/changes.rst),
thus this would probably kill Linux builds on BSDs and Darwin/MacOS.

But let me think about that a few days;  and perhaps someone else comes
up with an idea.

Kind regards,
Nicolas

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

[Nathan Chancellor]

On Fri, Jul 24, 2026 at 10:18:57PM +0200, Nicolas Schier wrote:
> On Wed, Jul 22, 2026 at 07:00:43PM +0000, Jaihind Yadav wrote:
> > 
> > Hi Nicolas Schier,
> > 
> > Thanks for the suggestion. I tested the proposed change:
> > 
> > -kstack-erase-cflags-y += -fplugin=$(objtree)/scripts/gcc-plugins/stackleak_plugin.so
> > +kstack-erase-cflags-y += -fplugin=scripts/gcc-plugins/stackleak_plugin.so
> > 
> > 
> > Unfortunately, it does not work for the out-of-tree module builds in
> > my environment.
> 
> Thanks for checking; and yes I forgot out-of-tree modules.  When
> building them, Kbuild changes to their respective output directory so my
> suggestion had to fail for oot kmods.

Technically, this is only a problem for out of tree kernel modules,
right? When building in-tree kernel modules, objtree is always '.', so
we will never have the output directory path in the debug information
(at least based on my brief testing).

> > Given that the proposed relative path breaks out-of-tree module
> > builds, could you please take a look at the patch I posted? If the
> > approach looks reasonable, I would appreciate your review and
> > consideration for merging it.
> 
> I am not sure, if we can take your path, as 'readlink --relative-to' is
> only available in coreutils/Linux but coreutils are not a documented
> requirement for Linux builds (cp. Documentation/process/changes.rst),
> thus this would probably kill Linux builds on BSDs and Darwin/MacOS.
> 
> But let me think about that a few days;  and perhaps someone else comes
> up with an idea.

Yeah, I don't really like 'realpath --relative-to' either, it feels a
bit like a hack since it will only avoid including a full path if the
module output directory includes part of the build directory. For
example:

  O=/mnt/build/kernel
  MO=/mnt/build/extmod

$ realpath -m --relative-to /mnt/build/extmod /mnt/build/kernel
../kernel

vs.

  O=/home/nathan/build/kernel
  MO=/mnt/build/extmod

$ realpath -m --relative-to /mnt/build/extmod /home/nathan/build/kernel
../../../home/nathan/build/kernel

Furthermore, this patch only fixes KSTACK_ERASE but we have other GCC
plugins that presumably have the same problem.

I do not have a good solution for this either but since it only affects
external kernel modules, I am not particularly inclined to think too
hard about it.

-- 
Cheers,
Nathan

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

[Jaihind Yadav]

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?

Thanks,
Jaihind

-----Original Message-----
From: Nathan Chancellor <nathan@kernel.org> 
Sent: Monday, August 3, 2026 11:42 PM
To: Nicolas Schier <nsc@kernel.org>
Cc: Jaihind Yadav <jaihindy@qti.qualcomm.com>; kees@kernel.org; linux-kbuild@vger.kernel.org; linux-hardening@vger.kernel.org; gustavoars@kernel.org; linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/1] scripts: kstack_erase: use relative stackleak plugin path

WARNING: This email originated from outside of Qualcomm. Please be wary of any links or attachments, and do not enable macros.

On Fri, Jul 24, 2026 at 10:18:57PM +0200, Nicolas Schier wrote:
> On Wed, Jul 22, 2026 at 07:00:43PM +0000, Jaihind Yadav wrote:
> >
> > Hi Nicolas Schier,
> >
> > Thanks for the suggestion. I tested the proposed change:
> >
> > -kstack-erase-cflags-y += 
> > -fplugin=$(objtree)/scripts/gcc-plugins/stackleak_plugin.so
> > +kstack-erase-cflags-y += 
> > +-fplugin=scripts/gcc-plugins/stackleak_plugin.so
> >
> >
> > Unfortunately, it does not work for the out-of-tree module builds in 
> > my environment.
>
> Thanks for checking; and yes I forgot out-of-tree modules.  When 
> building them, Kbuild changes to their respective output directory so 
> my suggestion had to fail for oot kmods.

Technically, this is only a problem for out of tree kernel modules, right? When building in-tree kernel modules, objtree is always '.', so we will never have the output directory path in the debug information (at least based on my brief testing).

> > Given that the proposed relative path breaks out-of-tree module 
> > builds, could you please take a look at the patch I posted? If the 
> > approach looks reasonable, I would appreciate your review and 
> > consideration for merging it.
>
> I am not sure, if we can take your path, as 'readlink --relative-to' 
> is only available in coreutils/Linux but coreutils are not a 
> documented requirement for Linux builds (cp. 
> Documentation/process/changes.rst),
> thus this would probably kill Linux builds on BSDs and Darwin/MacOS.
>
> But let me think about that a few days;  and perhaps someone else 
> comes up with an idea.

Yeah, I don't really like 'realpath --relative-to' either, it feels a bit like a hack since it will only avoid including a full path if the module output directory includes part of the build directory. For
example:

  O=/mnt/build/kernel
  MO=/mnt/build/extmod

$ realpath -m --relative-to /mnt/build/extmod /mnt/build/kernel ../kernel

vs.

  O=/home/nathan/build/kernel
  MO=/mnt/build/extmod

$ realpath -m --relative-to /mnt/build/extmod /home/nathan/build/kernel ../../../home/nathan/build/kernel

Furthermore, this patch only fixes KSTACK_ERASE but we have other GCC plugins that presumably have the same problem.

I do not have a good solution for this either but since it only affects external kernel modules, I am not particularly inclined to think too hard about it.

--
Cheers,
Nathan

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