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
