public inbox for
 help / color / mirror / Atom feed
From: Richard Purdie <>
To: Mark Wielaard <>
Cc:, Khem Raj <>,
	Sergio Durigan Junior <>
Subject: Re: Reproducible builds - supporting relative paths in *-prefix-map
Date: Wed, 17 Aug 2022 19:06:25 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <YvzPmkFjRR/>

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:


and libgcc being compiled here:


so relatively that is:


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! :)

Installation is configurable but usually in

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



      reply	other threads:[~2022-08-17 18:06 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-15 11:13 Richard Purdie
2022-08-15 14:26 ` Richard Purdie
2022-08-15 14:36   ` David Edelsohn
2022-08-15 17:15 ` Joseph Myers
2022-08-15 19:51   ` Richard Purdie
2022-08-15 19:55 ` Mark Wielaard
2022-08-15 20:29   ` Richard Purdie
2022-08-17 11:23     ` Mark Wielaard
2022-08-17 18:06       ` Richard Purdie [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).