When bitcoin is checked out in two directories (eg via git worktree) object files between the two will differ due to the full path being included in the debug section. -fdebug-prefix-map is used to replace this with "." to avoid this unnecessary difference and allow ccache to share objects between worktrees (provided the source and compile options are the same).
Also provide -fmacro-prefix-map if supported so that the working dir is not encoded in __FILE__ macros.
TIL.
Concept ACK.
Something could be said for also passing it in the non-debug case. After all, even without explicit debug information enabled, gcc adds some level of basic debug information like symbols, and yes this includes file paths:
$ strings -a src/bitcoind | grep /home/$USER|wc -l
1524
Not all of these come from debug information though! They may also be from __FILE__ macro. Is there a flag for that? E.g.:
$ objdump --dwarf=info src/bitcoind|grep DW_AT_comp_dir
<1a> DW_AT_comp_dir : (indirect string, offset: 0x9f): /home/…/projects/bitcoin/bitcoin/build/src
<282c9> DW_AT_comp_dir : (indirect string, offset: 0x9f): /home/…/projects/bitcoin/bitcoin/build/src
<1f2597> DW_AT_comp_dir : (indirect string, offset: 0x9f): /home/…/projects/bitcoin/bitcoin/build/src
<263930> DW_AT_comp_dir : (indirect string, offset: 0x9f): /home/…/projects/bitcoin/bitcoin/build/src
<399a44> DW_AT_comp_dir : (indirect string, offset: 0x9f): /home/…/projects/bitcoin/bitcoin/build/src
$ strip src/bitcoind
$ objdump --dwarf=info src/bitcoind|grep DW_AT_comp_dir
$ strings -a src/bitcoind | grep /home/$USER|wc -l
134
allow ccache to share objects between worktrees (provided the source and compile options are the same).
This sound sensible on first glance but does make me wonder how ccache "knows" this? When can it assume objects are portable between build directories. Does it explicitly pay attention to this flag?
Edit: also mind that if you're doing depends builds (I didn't in my examples above), things become even more complicated because the depends are also compiled from specific directories inside the specific work tree.
They may also be from FILE macro. Is there a flag for that? E.g.:
FWIW there's, starting with GCC 8, also -fmacro-prefix-map=old=new. Go wild :slightly_smiling_face:
And also a -ffile-prefix-map=old=new, apparently.
This sound sensible on first glance but does make me wonder how ccache "knows" this? When can it assume objects are portable between build directories. Does it explicitly pay attention to this flag?
Yeah:
$ strings /usr/bin/ccache | grep .-map
-fdebug-prefix-map=
-ffile-prefix-map=
-fmacro-prefix-map=
Not all of these come from debug information though! They may also be from
__FILE__macro.
Ah, gcc and clang are both giving me relative paths for __FILE__ even without any special options.
also mind that if you're doing depends builds (I didn't in my examples above), things become even more complicated ..
This doesn't pass the options through to even the in-tree submodules, so univalue and secp will continue getting the absolute path encoded; they don't take much time/space to compile though, so I figure that's okay.
And also a
-ffile-prefix-map=old=new, apparently.
I think clang supports -fdebug-prefix-map but not macro or file so I think it makes sense to just do debug and macro independently.
Added -fmacro-prefix-map and made them conditional on ccache being enabled.
When bitcoin is checked out in two directories (eg via git worktree)
object files between the two will differ due to the full path being
included in the debug section. -fdebug-prefix-map is used to replace
this with "." to avoid this unnecessary difference and allow ccache to
share objects between worktrees (provided the source and compile options
are the same).
Also provide -fmacro-prefix-map if supported so that the working dir is
not encoded in __FILE__ macros.
Yeah: $ strings /usr/bin/ccache | grep .-map -fdebug-prefix-map= -ffile-prefix-map= -fmacro-prefix-map=
Thanks, good to know.
Ah, gcc and clang are both giving me relative paths for FILE even without any special options.
It depends on what is passed to the compiler. I think for the macros they embed those paths literally. For the DWARF information, the absolute path is used (and there's also header paths, not just compilation unit paths). In any case there seems variance between systems and compilers here. As always…
Added -fmacro-prefix-map and made them conditional on ccache being enabled
Concept ACK on making it depend on --enable-ccache.
Concept ACK: path name leaking should be avoided
Anyone want to bump their acks from concept to reality?
cr ACK 7abac98d3e3c1bc8ad66cb5c05184b9c5cc674d5: patch looks correct
Concept ACK. Will test.
I think clang supports -fdebug-prefix-map but not macro or file so I think it makes sense to just do debug and macro independently.
There's:
-fdebug-prefix-map=OLD=NEW GCC (forever) & Clang 3.8+
-fmacro-prefix-map=OLD=NEW GCC 8+ Clang 10+
and also
-ffile-prefix-map=OLD=NEW GCC 8+ & Clang 10+.
which is just equal to -fdebug-prefix-map -fmacro-prefix-map; so setting both seems best for now. Could add a note that what were are doing is the equivalent to -ffile-prefix-map.
Looks like there's even a BUILD_PATH_PREFIX_MAP environment var under discussion.
ACK 7abac98d3e3c1bc8ad66cb5c05184b9c5cc674d5
Tested this using git worktrees and ccache. Doing something like:
# master
DIR A
./autogen.sh && ./configure --without-gui
gmake -C src/bitcoind
ccache --zero-stats
DIR B (git worktree)
./autogen.sh && ./configure --without-gui
gmake src/bitcoind -j8
hit rate:
cache miss 217
cache hit rate 0.00 %
# cleanup, remove worktree, nuke ccache
[#20353](/github-metadata-backup-bitcoin-bitcoin/20353/)
DIR A
./autogen.sh && ./configure --without-gui
gmake -C src/bitcoind
ccache --zero-stats
DIR B (git worktree different again)
./autogen.sh && ./configure --without-gui
gmake src/bitcoind -j8
hit rate:
cache miss 0
cache hit rate 100.00 %
Also tested when building using depends, configured via: ./autogen.sh && CONFIG_SITE=bitcoin/depends/x86_64-apple-darwin19.6.0/share/config.site ./configure
Wouldn't it be easier to set CCACHE_NOHASHDIR=1? Sure, the paths in the debug information might be wrong, but does it matter?
Wouldn't it be easier to set
CCACHE_NOHASHDIR=1? Sure, the paths in the debug information might be wrong, but does it matter?
AIUI, if the __FILE__ macro doesn't match (ie what macro-prefix-map fixes), the preprocessed input to ccache will be different, causing ccache misses. debug-prefix-map fixes the deug info paths, and then triggers ccache to automatically set CCACHE_NOHASHDIR=1. So these seems like the "proper" way to do it and it's not a big patch, so setting CCACHE_NOHASHDIR=1 doesn't seem that much easier?
Sure, just wanted to ask because the discussion didn't mention CCACHE_NOHASHDIR at all.