Re: RFC: Should -fplugin and -fplugin-arg options be excluded from DW_AT_producer recording?

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
> >>
> >>