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

Hi Richard,

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

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

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.

And it makes it so you can install the (debug) source files of all
packages/versions/arches in parallel without file conflicts.




  parent reply	other threads:[~2022-08-15 19:56 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 [this message]
2022-08-15 20:29   ` Richard Purdie
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).