[Bug gas/28266] New: CWD present in object file even after use of -fdebug-prefix-map=$PWD=foo

[joel at rosdahl dot net]

https://sourceware.org/bugzilla/show_bug.cgi?id=28266

            Bug ID: 28266
           Summary: CWD present in object file even after use of
                    -fdebug-prefix-map=$PWD=foo
           Product: binutils
           Version: 2.38 (HEAD)
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: gas
          Assignee: unassigned at sourceware dot org
          Reporter: joel at rosdahl dot net
  Target Milestone: ---

Hi there!

I'm the maintainer of ccache, a compiler cache which caches compilations based
on an input hash of various information such as the source code, compiler
arguments and some other pieces of information. If -g or similar is passed to
the compiler, ccache adds the CWD to the input hash since the object file then
will contain the CWD and therefore can't be part of a cache hit when the
compiler is run from another directory. However, if something like
-fdebug-prefix-map=$PWD=foo is used, ccache does not include CWD since the
debug paths then are normalized and the object file can be delivered as a cache
hit from other directories as well. Ccache has a test case that verifies this
assumption, and I recently got a bug report that the test case now fails on
Fedora 34 and rawhide: <https://github.com/ccache/ccache/issues/919>. I can
reproduce the problem on Fedora 34 with binutils-2.35.2-5.fc34.x86_64.rpm but
not with binutils-2.35.1-41.fc34.x86_64.rpm. My best guess is that this is due
to binutils commit 3417bfca676ff0b440f070a09837813e99b2c731 which seems to
unconditionally add CWD to the object file, hence filing this on the GAS
component. I'm not really familiar with the interaction between the compiler
and binutils, so bear with me. :-)

Is it expected that the 0'th entry in the directory table is not rewritten with
-fdebug-prefix-map? If not, I guess it breaks the intention of
-fdebug-prefix-map which is "This can give more reproducible builds, which are
location independent"?

I also noticed that 3417bfca676ff0b440f070a09837813e99b2c731 adds this comment:

    /* In DWARF-5 the 0 entry in the directory table is expected to be
       the same as the DW_AT_comp_dir (which is set to the current build
       directory).  Since we are about to create a directory entry that
       is not the same, allocate the current directory first.
       FIXME: Alternatively we could generate an error message here.  */

However, the 0'th entry in the directory table won't always be the same as
DW_AT_comp_dir since the latter value is rewritten by -fdebug-prefix-map.

Any thoughts on this would be welcome. I would like to understand what can be
done on the ccache side. Thanks!

-- 
You are receiving this mail because:
You are on the CC list for the bug.