Re: Reproducible builds - supporting relative paths in *-prefix-map

[Richard Purdie <richard.purdie@linuxfoundation.org>]

Hi Mark,

Thanks for the reply.

On Mon, 2022-08-15 at 21:55 +0200, Mark Wielaard wrote:
> I added Sergio to the CC since he was looking at debuginfo/DWARF
> relative paths created by -fdebug-prefix-map in Debian and having trouble
> making them work correctly. Maybe he has some feedback how to make
> this work.
> 
> On Mon, Aug 15, 2022 at 12:13:28PM +0100, Richard Purdie via Gcc wrote:
> > I'm wondering if we'd be able to improve path handling in the -f*-
> > prefix-map compiler options to cover relative paths?
> > [...]
> > In case it helps, my background on what I'm working on and why we'd
> > find this useful follows: 
> > 
> > I work on Yocto Project which cross compiles complete software stacks,
> > we use gcc heavily and the resulting builds are all around us. We care
> > deeply about build reproducibility.
> > 
> > With autotools, we long ago realised that we were best off separating
> > the source and the build output where we could and to do it we used
> > relative paths, which removed a lot of problematic hardcoded paths in
> > our output.
> > 
> > More recently we've been using -fdebug-prefix-map and -fmacro-prefix-
> > map (we need both since some of binutils doesn't seem to support the
> > combined version yet). We use the debug information (split separately)
> > to support on target debugging but where relative paths were used, we
> > miss information as the remapping either doesn't happen correctly or is
> > mangled. We'd like to fix our debug output but we're finding that hard
> > without relative path support for *prefix-map.
> 
> I might be misinterpreting the issue you are seeing.
> 
> But one problem with debuginfo/DWARF is that relative source paths
> aren't clearly defined. If you move or install the executable or
> (split) debug file out of the build directory a DWARF reader has no
> way to know what the paths are relative to.
> 
> So for DWARF the paths always have to be absolute (they can still be
> relative to the compilation dir (DW_AT_comp_dir), but at least that
> has to be absolute (and the compiler should turn any relative path
> into an absolute one or make sure they are relative to an absolute
> compilation directory path).

It gets slightly more complicated as we build in a directory separate
to the source where we can. Some source files are generated source
files and placed in the build directory whilst many are in the source
directory. DW_AT_comp_dir can be set to one or the other but it is the
relative path between build and source which is problematic.

> The problem with that is a) it makes the binary (debuginfo) output
> dependent on the build srcdir and builddir and b) to support
> debugging/tracing/profiling tools the user has to install the (debug)
> sources under those exact same directories on their local machine.
> 
> One way around this is to use -fdebug-prefix-map with an absolute
> paths under which you will also install any source files. Or to use
> debugedit [*] after the build to rewrite the build dir path to
> something like /usr/debug/src/<package-version-release-archa> which is
> what some distros do.
> 
> e.g. Fedora has (one or more) binary package, a debuginfo package for
> the .debug files (optionally installed under /usr/lib/debug) and
> debugsource package for the debug source files (optionally installed
> under /usr/debug/src). These packages can then also be used to
> dynamically find any debug or source file when indexed by debuginfod
> [**].

We split the debuginfo into a separate package. We also look at the
sources it references and those go into a different separate package
too. We support populating a remote debuginfod server with these or
installing them onto the target.

> Using known absolute paths generated with debugedit or
> -fdebug-prefix-map makes sure the paths used in the debuginfo/DWARF
> are always the same independent from the current srcdir or builddir to
> make them reproducible. And the user/tools don't have to guess what
> the relative paths are relative to.

We have that working and set debug-prefix-map today. What is
problematic is trying to recreate the relative paths on target between
our source and build directories. Currently, most generated files in
the build directory just don't get handled correctly on target. We'd
like to fix that. There is currently no way to remap a relative path
though, at least as far as I could determine.

Cheers,

Richard