We've noticed similar issue in Chrome: https://bugs.chromium.org/p/chromium/issues/detail?id=764484

We verified the following:

1) the target has been compiled with proper flags
2) the code we're interested in is definitely being executed
3) the code has profiler instrumentation 

However, we are getting the warning + coverage report doesn't show anything for the files we are interested in.

It's worth to mention that the target is fairly large (CSS parser that is linked with lots of Blink stuff).

llvm-cov's diagnostic for this problem is a bit better now (r313853). If you pass "-dump" along with your regular llvm-cov invocation, you should see messages like:

hash-mismatch: No profile record found for 'main' with hash = 0xA

I've added some explanations of what these mismatches mean in the doxygen comments for the CoverageMapping class. Hopefully that will make it easier to figure out which object file contribute profile records with unexpected hashes.

I've also just built ToT clang, run "clang -help", merged the raw profile, and invoked llvm-cov. I get no function mismatches. Merging in profiles from a few additional clang invocations is also no issue. We get mismatches only after merging in profiles from other tools (llvm-tblgen, llc, FileCheck, etc).

To avoid this problem, we could name profiles in a way that makes it hard to merge together profiles for different binaries. E.g, that means teaching FileCheck to write to "FileCheck_%m.profraw", llc to "llc_%m.profraw", etc. But before doing that, we should narrow down the cause of the mismatches.

Thanks for clarifications, Vedant! We'll take a closer look using the ToT revision and "-dump" option. Will post an update after that.

Forwarding a comment from Chromium bug tracker:

I have built ToT llvm and clang and used them to build my fuzzer and generate the coverage report, and the issue remains.

After using the -dump option with llvm-cov, it complains that 148 functions have mismatched data and then prints 148 lines similar to the one below:

hash-mismatch: No profile record found for '_ZN7logging11CheckGEImplEiiPKc' with hash = 0x0

In all of these cases, the hash was 0x0 and the function name was some kind of mangled name (like the one above) beginning with the prefix "_ZN"

The root cause seems to be a 0 hash (see https://bugs.chromium.org/p/chromium/issues/detail?id=764484#c14)

Also Jonathan came up with a small reproducer:

printf '#include <iostream>\n void h() {std::cout << 1 << std::endl;} int main() {h();h();h();return 0;}' > test.cc; clang++ -fprofile-instr-generate -fcoverage-mapping test.cc -o test; LLVM_PROFILE_FILE=test.profdata ./test >/dev/null; llvm-profdata show test.profdata -all-functions

The output of which is:

Counters:
  _Z1hv:
    Hash: 0x0000000000000000
    Counters: 1
    Function count: 3
  main:
    Hash: 0x0000000000000000
    Counters: 1
    Function count: 1
Functions shown: 2
Total functions: 2
Maximum function count: 3
Maximum internal block count: 0



llvm-cov doesn't complain though

> hash-mismatch: No profile record found for '_ZN7logging11CheckGEImplEiiPKc' with hash = 0x0

It's OK for functions to have a hash equal to 0. The question is, why does the profile record found for '_ZN7logging11CheckGEImplEiiPKc' *not* have a hash equal to 0?

Vedant, it looks like we've been seeing that issue even with fresh clang revision because we had some dynamic libraries linked in, instead of using static linking. We cannot reproduce it anymore since we started explicitly enable static linking for our targets. Thanks a lot for your help!

I'm glad you are unblocked but am worried that there are issues using dylibs. Please do let me know if you see more instances of suspicious hash mismatches, and I'll try and set aside more time to reduce the issue.