clang's -fprofile-use= generates false hits, causes clang to generate invalid objects

[trofi]

It's a trimmed-down version of https://bugs.gentoo.org/718632 where firefox being built under ccache causes llvm to SIGSEGV. Mechanically happens because profile data (up-to-date) does not match instrumented objects (cached against older profile data).

Here is a self-contained example:

Prerequisite files:

// $ cat a.c
void f(){}
void g(){}
void h(){}
int main() { f(); g(); f(); h(); }

#!/bin/bash

# cat bug.bash

# verbose logging if ccache triggers
export CCACHE_DEBUG=1

CC='clang'

$CC -fprofile-generate=profs -o a.o -c a.c
$CC -fprofile-generate=profs -o a      a.o -fuse-ld=lld

./a

llvm-profdata merge -output=profdata.merged profs
# print hash to show that profiling data changes all the time
sha1sum profdata.merged

$CC -fprofile-use=profdata.merged -o p-a.o -c   a.c
$CC -fprofile-use=profdata.merged -o p-a      p-a.o -fuse-ld=lld

fgrep Result *.ccache-log

Actual test:

$ ./bug.bash
f70223948e24fb9948ecfff4136cb936dfc6100d  profdata.merged
a.o.ccache-log:[2020-04-21T19:18:08.225187 2162504] Result: cache miss
p-a.o.ccache-log:[2020-04-21T19:18:08.439474 2162522] Result: cache miss
$ ./bug.bash
b0e197cc8cae70e950c288dfe9182ca6886bb2d8  profdata.merged
a.o.ccache-log:[2020-04-21T19:18:11.206210 2162539] Result: cache hit (direct)
p-a.o.ccache-log:[2020-04-21T19:18:11.312192 2162555] Result: cache hit (direct)

Note: profdata.merged changed (insubstantially in this case), but p-a.o did hit the cache.

p-a.o.ccache-log hints at gcc-style profiling info format:

...
[2020-04-21T19:18:11.286446 2162555] Adding profile data =profdata.merged/p-a.gcda to our hash
[2020-04-21T19:18:11.286456 2162555] Failed to open =profdata.merged/p-a.gcda: No such file or directory
[2020-04-21T19:18:11.286477 2162555] Looking for object file hash in /gentoo/ccache/b/0/7673814d86a406033e5ffb4ea65572-601.manifest
[2020-04-21T19:18:11.286540 2162555] Got object file hash from manifest
[2020-04-21T19:18:11.286604 2162555] Copying /gentoo/ccache/a/e/3b3f6f44108831c470a42131c1cec3-685.o to p-a.o via p-a.o.sf.2162555.h1KDKu (uncompressed)
[2020-04-21T19:18:11.286746 2162555] Created from cache: /gentoo/ccache/a/e/3b3f6f44108831c470a42131c1cec3-685.o -> p-a.o

It looks like LLVM's profiling modes differ quite a bit from gcc's:

• https://clang.llvm.org/docs/UsersManual.html : llvm uses -fprofile-use=file-as-is or -fprofile-use=directory with default.profdata. And a few other options around environment variables and other options that influence profiling.
• https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html : gcc uses -fprofile-use=directory with .gcda files in it.

AFAIU .gcda is what ccache implements today.

Tested on ccache version 3.7.9

[jrosdahl]

Thanks for the bug report. The support for profiling options was added in 2011 in #2 when (unless I'm mistaken) Clang didn't have any such options, and ccache didn't claim to support Clang anyway. It also seems like it hasn't aged well for GCC either.

It looks like ccache still works for

• -fprofile-generate + -fprofile-use for GCC (all versions)
• -fprofile-generate=path + -fprofile-use=path for GCC <9

but not for

• -fprofile-generate + -fprofile-use for Clang
• -fprofile-generate=path + -fprofile-use=path for GCC ≥9 and Clang

The behavior of profiling options has become very complex since last I looked. I'm not sure if we should just remove the support or if there's a reasonably simple fix.

[jrosdahl]

Since ccache doesn't know the GCC version, the only thing I think is left to support with reasonable effort is GCC's -fprofile-generate + -fprofile-use (without =path) when -fprofile-dir is not used. That's very a narrow use case so it might be best to just remove the support (i.e., fall back to run the compiler without trying to cache anything). I'll sleep on it a bit.