[ccache] ccache and -g
cswiedler at perpetual.com
Wed Jan 4 01:34:04 GMT 2006
Looking at CCACHE_UNIFY: what exactly is the problem mentioned in the
docs about using CCACHE_UNIFY, for example with debugging (gcc -g)? It
looks to me like the compiler is always run (on a cache miss) on the
original source, and the unification is done only for generating the
hash. If that's the case, how are compiler warning messages outputting
the wrong lines, and why is it forced off for debug compiles?
In terms of getting cache hits, forcing the unifier to be run (via
Steve's patch) fixes my problem, since it removes lines beginning with #
from the hash. That's a little more extreme than I need; I would be
happy if the unifier just ignored lines beginning with # which refer to
a directory instead of a file. In my case, the only line which is
different between the preprocessed output of two identical files in
different trees is the second line, which looks like
# 1 "/home/current/path//"
> -----Original Message-----
> From: Martin Pool [mailto:mbp at sourcefrog.net]
> Sent: Tuesday, January 03, 2006 2:37 PM
> To: Chris Swiedler
> Cc: ccache at lists.samba.org
> Subject: Re: [ccache] ccache and -g
> On 3 Jan 2006, Chris Swiedler <cswiedler at perpetual.com> wrote:
> > Is there any way to get ccache to work well with the -g
> option to gcc,
> > which embeds the absolute path of the source file in the
> > output? I would like to be able to build the same file (and options,
> > etc) in different locations and have ccache see them as
> identical files.
> > This will cause gdb to sometimes think the source files come from a
> > different location, but I'm okay with this since the files will be
> > identical anyway.
> > Looking at the preprocessor output (with -g enabled) from two
> > identical files in different trees, the only difference is
> the second
> > line which contains the path of the source file. This line doesn't
> > appear at all if -g is not enabled. If I modified ccache to exclude
> > this line from the hash, would this have strange consequences?
> I think that would be fine. There are already options that
> do similar things (e.g. CCACHE_UNIFY). Please post the patch
> if you do this change.
More information about the ccache