[PATCH] ccache: Disable CCACHE_HASHDIR by default

[PATCH] ccache: Disable CCACHE_HASHDIR by default

[Mike Crowe]

As of ccache-3.3, ccache will always include the current directory
in the hash when the compiler is configured to output debug
information. The current directory will change every time ${PV}
changes, which will invalidate the cache.

ccache apparently does this so that paths in the debug information will
always be correct. In an OE world these paths may already be missing or
incorrect due to rm_work or the use of a shared sstate cache, so it doesn't
seem as if we're losing much by disabling this feature.

Signed-off-by: Mike Crowe <mac@mcrowe.com>
---
 meta/classes/ccache.bbclass | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/meta/classes/ccache.bbclass b/meta/classes/ccache.bbclass
index 76c8828..6b20846 100644
--- a/meta/classes/ccache.bbclass
+++ b/meta/classes/ccache.bbclass
@@ -2,6 +2,13 @@ CCACHE = "${@bb.utils.which(d.getVar('PATH'), 'ccache') and 'ccache '}"
 export CCACHE_DIR ?= "${TMPDIR}/ccache/${MULTIMACH_HOST_SYS}/${PN}"
 CCACHE_DISABLE[unexport] = "1"
 
+# As of ccache-3.3, ccache will always include the current directory
+# in the hash when the compiler is configured to output debug
+# information. The current directory will change every time ${PV}
+# changes which greatly reduces the utility of ccache. So, let's not
+# consider the current directory to be significant by default.
+export CCACHE_NOHASHDIR ?= "1"
+
 DEPENDS_append_class-target = " ccache-native"
 DEPENDS[vardepvalueexclude] = " ccache-native"
 
-- 
2.1.4

Re: [PATCH] ccache: Disable CCACHE_HASHDIR by default

[Burton, Ross]

[-- Attachment #1: Type: text/plain, Size: 548 bytes --]

On 11 March 2017 at 16:54, Mike Crowe <mac@mcrowe.com> wrote:

> ccache apparently does this so that paths in the debug information will
> always be correct. In an OE world these paths may already be missing or
> incorrect due to rm_work or the use of a shared sstate cache, so it doesn't
> seem as if we're losing much by disabling this feature.
>

In an OE world we tell GCC to rewrite them to be target paths anyway, so
this isn't a problem.  Maybe worth rewriting the commit message?

(see bitbake.conf, -fdebug-prefix-map)

Ross

[-- Attachment #2: Type: text/html, Size: 1029 bytes --]

Re: [PATCH] ccache: Disable CCACHE_HASHDIR by default

[Mike Crowe]

On Monday 13 March 2017 at 13:33:27 +0000, Burton, Ross wrote:
> On 11 March 2017 at 16:54, Mike Crowe <mac@mcrowe.com> wrote:
> 
> > ccache apparently does this so that paths in the debug information will
> > always be correct. In an OE world these paths may already be missing or
> > incorrect due to rm_work or the use of a shared sstate cache, so it doesn't
> > seem as if we're losing much by disabling this feature.
> >
> 
> In an OE world we tell GCC to rewrite them to be target paths anyway, so
> this isn't a problem.  Maybe worth rewriting the commit message?
> 
> (see bitbake.conf, -fdebug-prefix-map)

I wasn't aware of that.

ccache does have some technology to detect this situation:

  Exception: The CWD will not be included in the hash if *base_dir* is set
  (and matches the CWD) and the compiler option *-fdebug-prefix-map* is
  used.

I think this means that if CCACHE_BASEDIR is set appropriately then it
wouldn't be necessary to set CCACHE_NOHASHDIR. (Looking at the ccache code,
I think that "matches the CWD" means "CWD is under *base_dir*" rather than
the two needing to be identical.)

I shall investigate why things weren't working correctly for us. In the
meantime I don't think my patch is yet proven to be doing the right thing.

Thanks.

Mike.

Re: [PATCH] ccache: Disable CCACHE_HASHDIR by default

[Mike Crowe]

On Monday 13 March 2017 at 13:51:46 +0000, Mike Crowe wrote:
> On Monday 13 March 2017 at 13:33:27 +0000, Burton, Ross wrote:
> > On 11 March 2017 at 16:54, Mike Crowe <mac@mcrowe.com> wrote:
> > 
> > > ccache apparently does this so that paths in the debug information will
> > > always be correct. In an OE world these paths may already be missing or
> > > incorrect due to rm_work or the use of a shared sstate cache, so it doesn't
> > > seem as if we're losing much by disabling this feature.
> > >
> > 
> > In an OE world we tell GCC to rewrite them to be target paths anyway, so
> > this isn't a problem.  Maybe worth rewriting the commit message?
> > 
> > (see bitbake.conf, -fdebug-prefix-map)
> 
> I wasn't aware of that.
> 
> ccache does have some technology to detect this situation:
> 
>   Exception: The CWD will not be included in the hash if *base_dir* is set
>   (and matches the CWD) and the compiler option *-fdebug-prefix-map* is
>   used.
> 
> I think this means that if CCACHE_BASEDIR is set appropriately then it
> wouldn't be necessary to set CCACHE_NOHASHDIR. (Looking at the ccache code,
> I think that "matches the CWD" means "CWD is under *base_dir*" rather than
> the two needing to be identical.)
> 
> I shall investigate why things weren't working correctly for us. In the
> meantime I don't think my patch is yet proven to be doing the right thing.

Unfortunately ccache only supports this special behaviour for the last
-fdebug-prefix-map argument. All the arguments make it through to the
compiler, but the last one isn't enough to stop the current directory being
hashed by default.

I've raised this as https://github.com/ccache/ccache/issues/163 .

It seems that for the time being setting CCACHE_NOHASHDIR is required to
make ccache effective for us. I'll reword the commit message based on
Ross's input and this information.

Thanks.

Mike.

Re: [PATCH] ccache: Disable CCACHE_HASHDIR by default

[Mike Crowe]

On Wednesday 15 March 2017 at 11:54:19 +0000, Mike Crowe wrote:
> On Monday 13 March 2017 at 13:51:46 +0000, Mike Crowe wrote:
> > On Monday 13 March 2017 at 13:33:27 +0000, Burton, Ross wrote:
> > > On 11 March 2017 at 16:54, Mike Crowe <mac@mcrowe.com> wrote:
> > > 
> > > > ccache apparently does this so that paths in the debug information will
> > > > always be correct. In an OE world these paths may already be missing or
> > > > incorrect due to rm_work or the use of a shared sstate cache, so it doesn't
> > > > seem as if we're losing much by disabling this feature.
> > > >
> > > 
> > > In an OE world we tell GCC to rewrite them to be target paths anyway, so
> > > this isn't a problem.  Maybe worth rewriting the commit message?
> > > 
> > > (see bitbake.conf, -fdebug-prefix-map)
> > 
> > I wasn't aware of that.

It turns out that I wasn't aware of it because meta-micro overwrites
FULL_OPTIMIZATION, so we don't end up using DEBUG_FLAGS. :(

I'm not sure that putting DEBUG_FLAGS in FULL_OPTIMIZATION makes sense
since its value has nothing to do with optimization. It appears to have
been this way since the individual flags were extracted from
FULL_OPTIMIZATION into DEBUG_FLAGS in 2011 in
9cb7113790d716a4c5cf7d511535ba87fdecd1ac .

Perhaps DEBUG_FLAGS should go into TARGET_CFLAGS directly? If I were to
prepare and test a patch to do that, would it be well received?

> > ccache does have some technology to detect this situation:
> > 
> >   Exception: The CWD will not be included in the hash if *base_dir* is set
> >   (and matches the CWD) and the compiler option *-fdebug-prefix-map* is
> >   used.
> > 
> > I think this means that if CCACHE_BASEDIR is set appropriately then it
> > wouldn't be necessary to set CCACHE_NOHASHDIR. (Looking at the ccache code,
> > I think that "matches the CWD" means "CWD is under *base_dir*" rather than
> > the two needing to be identical.)
> > 
> > I shall investigate why things weren't working correctly for us. In the
> > meantime I don't think my patch is yet proven to be doing the right thing.
> 
> Unfortunately ccache only supports this special behaviour for the last
> -fdebug-prefix-map argument. All the arguments make it through to the
> compiler, but the last one isn't enough to stop the current directory being
> hashed by default.
> 
> I've raised this as https://github.com/ccache/ccache/issues/163 .

That bug has now apparently been fixed in ccache, although there has not
yet been a release containing the fix.

> It seems that for the time being setting CCACHE_NOHASHDIR is required to
> make ccache effective for us. I'll reword the commit message based on
> Ross's input and this information.

The patch with the reworded commit message went in as
fb7a5cdcff19bb44a25a51e20de0440c1ebcc057. 

I've tested ccache with the multiple -fdebug-prefix-map fix patched in.
Unfortunately, it still doesn't work as well as I'd hoped without
CCACHE_NOHASHDIR because bitbake.conf sets DEBUG_PREFIX_MAP to contain:

 -fdebug-prefix-map=${WORKDIR}=/usr/src/debug/${PN}/${EXTENDPE}${PV}-${PR}

so every time PV or PR changes the ccache hash changes even when the actual
source hasn't. :( Luckily, setting CCACHE_NOHASHDIR means that none of the
debug prefix maps are considered significant for the hash anyway.

So I think that this means, even if a version of ccache containing the
-fdebug-prefix-map fix is merged, it is still necessary to set
CCACHE_NOHASHDIR for ccache to be effective, but that runs the risk of
debug information being incorrect.

The use of PV and PR was added in ecb56a6ae0c870af680da03db9d39703b525fc98
in order to cope with debug packages that contain the full source. That's
not a feature we use, so I'm not sure whether it would continue to work if
DEBUG_PREFIX_MAP were instead just to contain:

 -fdebug-prefix-map=${WORKDIR}=/usr/src/debug/${PN}

?

Mike.