On Wed, Aug 19, 2026 at 7:35 AM Jaihind Yadav <[email protected]> wrote: > > Hi Richard, Pietro, > > Thanks for the feedback. I tested Pietro’s suggestion with a minimal > reproducer and a local dummy plugin. > > I compiled hello.c with: > > - -g -grecord-gcc-switches -fplugin=<absolute-path> > > Then repeated with: > > 1. -fdebug-prefix-map=/tmp/gcc_plugin_map_test3=REMAP > 2. -fdebug-prefix-map targeting the plugin directory specifically > 3. -ffile-prefix-map=/tmp/gcc_plugin_map_test3=REMAP > 4. -fmacro-prefix-map=/tmp/gcc_plugin_map_test3=REMAP > 5. -fdebug-prefix-map + -ffile-prefix-map > 6. Control: -gno-record-gcc-switches > > Validation: > > - Checked DW_AT_producer via readelf --debug-dump=info. > > Findings: > > - In cases (1)–(5), DW_AT_producer still contained the absolute plugin path > from -fplugin=.... > - Only case (6) removed -fplugin from DW_AT_producer. > > So in this environment (GCC 13.3.0), the prefix-map options do not > rewrite/sanitize the plugin path when GCC switch recording is enabled.
It's IMO also a good suggestion to make -f*-prefix-map affect the -fplugin argument. Richard. > Thanks, > Jaihind Yadav > > -----Original Message----- > From: Pietro Monteiro <[email protected]> > Sent: Sunday, August 16, 2026 8:06 PM > To: Richard Biener <[email protected]>; Jaihind Yadav > <[email protected]> > Cc: [email protected]; [email protected] > Subject: Re: RFC: Should -fplugin and -fplugin-arg options be excluded from > DW_AT_producer recording? > > WARNING: This email originated from outside of Qualcomm. Please be wary of > any links or attachments, and do not enable macros. > > On Fri, Aug 14, 2026, at 2:16 AM, Richard Biener via Gcc wrote: > > On Wed, Aug 12, 2026 at 12:40 PM Jaihind Yadav > > <[email protected]> wrote: > >> > >> Hi, > >> > >> > >> > >> While investigating a build-path leakage issue, I noticed that > >> > >> -fplugin=<path> and -fplugin-arg-* options are currently recorded in > >> > >> DW_AT_producer when -grecord-gcc-switches is enabled. > >> > >> > >> > >> As a result, an absolute plugin path may become embedded in debug > >> > >> metadata. > >> > >> > >> > >> For example: > >> > >> > >> > >> gcc -g -grecord-gcc-switches \ > >> > >> -fplugin=/path/to/plugin.so \ > >> > >> -c hello.c > >> > >> > >> > >> produces an object file whose DW_AT_producer contains: > >> > >> > >> > >> GNU C23 ... -g -fplugin=/path/to/plugin.so > >> > >> > >> > >> In my case, the recorded path was an absolute build-system path to a > >> > >> GCC plugin: > >> > >> > >> > >> -fplugin=/local/.../scripts/gcc-plugins/stackleak_plugin.so > >> > >> > >> > >> This introduces host-specific path information into the generated > >> > >> artifact and may negatively affect reproducibility. > >> > >> > >> > >> I noticed that GCC already has the NoDWARFRecord mechanism for > >> options > >> > >> that should not be recorded in the producer string. Looking through > >> the > >> > >> history, it appears that this mechanism was introduced partly to > >> address > >> > >> reproducibility concerns involving path-containing options, and there > >> > >> are also examples where specific options are intentionally excluded > >> from > >> > >> producer-string recording. > >> > >> > >> > >> As an experiment, I modified: > >> > >> > >> > >> gcc/common.opt > >> > >> > >> > >> and marked: > >> > >> > >> > >> -fplugin= > >> > >> -fplugin-arg-* > >> > >> > >> > >> with NoDWARFRecord. > >> > >> > >> > >> With this change: > >> > >> > >> > >> Before: > >> > >> DW_AT_producer: > >> > >> GNU C23 ... -g \ > >> > >> -fplugin=/local/.../stackleak_plugin.so > >> > >> > >> > >> After: > >> > >> DW_AT_producer: > >> > >> GNU C23 ... -g > >> > >> > >> > >> The plugin is still loaded correctly, plugin arguments are still > >> passed, > >> > >> and generated code/debug information remain unchanged. The only > >> observed > >> > >> difference is that plugin-related command-line options are no longer > >> > >> recorded in DW_AT_producer. > >> > >> > >> > >> The tradeoff appears to be: > >> > >> > >> > >> Benefits: > >> > >> - Avoids recording host-specific absolute plugin paths. > >> > >> - Improves reproducibility of producer strings. > >> > >> - Reduces leakage of local build environment details. > >> > >> > >> > >> Downsides: > >> > >> - Reduces provenance information available from DW_AT_producer. > >> > >> - Makes it harder to determine from the binary alone which GCC plugin > >> > >> (and plugin arguments) were used during compilation. > >> > >> > >> > >> Before preparing a formal patch submission, I would like feedback on > >> the > >> > >> policy aspect: > >> > >> > >> > >> Should -fplugin and -fplugin-arg-* be treated similarly to other > >> > >> path-sensitive options and be excluded from producer-string > >> > >> recording? > > > > No, they should not be excluded as they are clearly affecting the > > compilation. Is there not a standard plugin search path so the build > > systems can use -fplugin=<name>.so without path? > > Can you test the effect of -fdebug-prefix-map and other path options on > plugin path recording? > > https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html#index-fdebug-prefix-map > > pietro > > >> > >> > >> > >> or > >> > >> > >> > >> Is preserving plugin provenance in DW_AT_producer considered more > >> > >> valuable than avoiding path leakage and reproducibility issues? > >> > >> > >> > >> Comments and guidance would be appreciated. > >> > >> > >> > >> Thanks, > >> > >> Jaihind Yadav > >> > >>
