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: Mon, 15 Aug 2022 21:29:03 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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.



  reply	other threads:[~2022-08-15 20:29 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 [this message]
2022-08-17 11:23     ` Mark Wielaard
2022-08-17 18:06       ` Richard Purdie

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