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

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

Hi Mark,

Thanks for the reply!

On Wed, 2022-08-17 at 13:23 +0200, Mark Wielaard wrote:
> Hi Richard,
> 
> On Mon, Aug 15, 2022 at 09:29:03PM +0100, Richard Purdie wrote:
> > On Mon, 2022-08-15 at 21:55 +0200, Mark Wielaard wrote:
> > > 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.
> 
> Could you give an example directory structure when that creates a
> problem? Any debug paths generated should be absolute or relative to
> an absolute path.  In particular the DW_AT_comp_dir is normally an
> absolute path (getpwd). So normally just remapping some prefix of the
> pwd (either srcdir and/or builddir) should work to keep the relative
> paths correct when moving the (generated) sources under that new
> absolute path. I am probably missing something about the directory
> setup that makes that reasoning invalid.

An example from my build machine would be the gcc source here:

/media/build1/poky/build/tmp/work-shared/gcc-12.1.0-r0/gcc-12.1.0/

and libgcc being compiled here:

/media/build1/poky/build/tmp/work/core2-64-poky-linux/libgcc/12.1.0-r0/gcc-12.1.0/build.x86_64-poky-linux.x86_64-poky-linux

so relatively that is:

../../../work/core2-64-poky-linux/libgcc/12.1.0-r0/gcc-12.1.0/build.x86_64-poky-linux.x86_64-poky-linux

On target we put the gcc source at /usr/src/debug/gcc/12.1.0/.

To make this work we'd have to put the actual gcc source three levels
under that, and replicate the "work/core2-64-poky-linux/libgcc/12.1.0-
r0/gcc-12.1.0/build.x86_64-poky-linux.x86_64-poky-linux" structure,
neither of which are things we really want to do.

It gets more complicated as we support the idea of "external source"
which is from an arbitrary location on the system but built within
tmp/work/xxx. In the general case we can't remap all possibilities.

> > e 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.
> 
> Nice. How do you lookup the referenced sources and where are they
> then installed?

We use dwarfsrcfiles which it looks like you may have written! :)

https://git.yoctoproject.org/poky/tree/meta/recipes-devtools/dwarfsrcfiles/files/dwarfsrcfiles.c

Installation is configurable but usually in
/usr/src/debug/<recipename>/<version>/

> > > 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.
> 
> So is the problem that when collecting the generated source files you
> cannot map the debug-prefix-map back anymore?

Correct, if we build with relative paths to autoconf (which we
effectively have to so we can avoid lots of full path hardcoding), we
can't collect up and remap the generated files.

>  The relative paths are relative to the original (absolute) prefix, but 
> you only have the remapped prefix?

We can't recreate the relative paths on target (in the general external
source case) and we can't remap them with the code as it stands today.

Cheers,

Richard