public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Joseph Myers <joseph@codesourcery.com>
To: Richard Purdie <richard.purdie@linuxfoundation.org>
Cc: <gcc@gcc.gnu.org>, Khem Raj <raj.khem@gmail.com>
Subject: Re: Reproducible builds - supporting relative paths in *-prefix-map
Date: Mon, 15 Aug 2022 17:15:46 +0000	[thread overview]
Message-ID: <alpine.DEB.2.22.394.2208151709180.311521@digraph.polyomino.org.uk> (raw)
In-Reply-To: <1c0ab23fd0cc1bc34a229287529963526141327a.camel@linuxfoundation.org>

On Mon, 15 Aug 2022, Richard Purdie via Gcc wrote:

> Currently it works well for absolute paths but if a file uses a
> relative path or a path with a symlink in, or a non-absolute path, it
> will miss those cases. For relative paths in particular it is
> problematic as you can't easily construct a compiler commandline that
> would cover all relative path options.

I'd expect a relative path to be naturally relocatable without needing to 
be remapped.  (For example, DW_AT_comp_dir would be relocated in debug 
info, but there would be no need to relocate the paths to individual files 
that are relative to DW_AT_comp_dir.)

Is the issue that you're using relative paths between two directories that 
don't have a fixed relative path between them, such as between the build 
and source directories, as opposed to relative paths within the source 
directory or within the build directory?

> which address a realpath() call into the prefix mapping code. I did

That would run the risk of breaking relocation for anyone who has 
deliberately used the paths they pass to the compiler (possibly involving 
symlinks, for example) in their remapping options - not expecting a 
further level of processing to be applied to those paths before remapping.

-- 
Joseph S. Myers
joseph@codesourcery.com

  parent reply	other threads:[~2022-08-15 17:15 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 [this message]
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

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=alpine.DEB.2.22.394.2208151709180.311521@digraph.polyomino.org.uk \
    --to=joseph@codesourcery.com \
    --cc=gcc@gcc.gnu.org \
    --cc=raj.khem@gmail.com \
    --cc=richard.purdie@linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

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