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 <[email protected]> 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. -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
