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' <[email protected]> Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected] 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 <[email protected]> Sent: Wednesday, July 22, 2026 8:16 PM To: Jaihind Yadav <[email protected]> Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected] 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
