Reproducible builds vs debugedit vs relative debug paths

[Mark Wielaard]

Hi reproducible builders,

"debugedit https://sourceware.org/debugedit provides programs and
scripts for creating debuginfo and source file distributions, collect
build-ids and rewrite source paths in DWARF data for debugging,
tracing and profiling."

For the "rewrite source paths in DWARF data" part we recently hit a
bug because debugedit doesn't handle rewriting relative paths. We
might be able to fix that bug, but it isn't precisely clear what the
path is relative to when multiple object files build in different
directories are linked together. So we would like to recommend people
avoid creating these relative paths.
https://sourceware.org/bugzilla/show_bug.cgi?id=33823
https://sourceware.org/bugzilla/show_bug.cgi?id=33602

But then we found https://reproducible-builds.org/docs/build-path/
which explicitly seems to recommend using them. And has a note on
debugedit:
https://reproducible-builds.org/docs/build-path/#fn:debugedit

  debugedit can replace the path used at build time by a
  predefined one but it does that by rewriting bytes in place.
  As this does not reorder the hash table of strings,
  the resulting bytes are still depending on the original
  build path.

I wonder if that comment might be based on some older version of
debugedit? Current versions do rewrite the .debug_str and other
similar string tables. But maybe I am missing something else that
makes debugedit not deterministic in path rewriting.

Have people tried more modern versions of debugedit to get
deterministic (absolute) DWARF paths and found issues with it?

Thanks,

Mark