-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
C++ Coverage on MacOS is completely broken #10457
Comments
This allows setting GCOV on the command line to overwrite the default setting, which points to /usr/bin/gcov. In order to use this, you also need to disable the gcov coverage feature and enable the llvm coverage feature instead. The full command-line looks like this: GCOV=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/llvm-profdata bazel coverage --features=llvm_coverage_map_format --features=-gcc_coverage_map_format //cpp:test Progress on #10457. Change-Id: Iae80e3a5830711b6402a3e015bf9ae12b536f429 Closes #10640. Change-Id: Iae80e3a5830711b6402a3e015bf9ae12b536f429 PiperOrigin-RevId: 291701448
On MacOS, setting GCOV_PREFIX_STRIP to 3 is generally incorrect. This setting works on Linux, because we set PWD=/proc/self/cwd/, which makes all paths have a fixed 3-segment prefix. However, this is not possible on MacOS. On MacOS, the correct setting depends on the path to the exec root or the sandbox root (if sandboxing is enabled). On my machine, the proper value is 10. While this change doesn't fix the underlying issue, at least it allows users to work around it without having to modify and compile Bazel from source. Related to #10457. PiperOrigin-RevId: 291701562
This allows setting GCOV on the command line to overwrite the default setting, which points to /usr/bin/gcov. In order to use this, you also need to disable the gcov coverage feature and enable the llvm coverage feature instead. The full command-line looks like this: GCOV=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/llvm-profdata bazel coverage --features=llvm_coverage_map_format --features=-gcc_coverage_map_format //cpp:test Progress on #10457. Original change by ulfjack RELNOTES: None. PiperOrigin-RevId: 300583709
Define configuration options for collecting coverage data with Bazel. The coverage command for Bazel is fairly fragile and many configurations do not work [1,2]. The `--javabase` option is set as suggested in this bug report[3]. Coverage has been manually tested with GCC 7 on Ubuntu 18.04. [1]: bazelbuild/bazel#9406 [2]: bazelbuild/bazel#10457 [3]: bazelbuild/bazel#7953
Define configuration options for collecting coverage data with Bazel. The coverage command for Bazel is fairly fragile and many configurations do not work [1,2]. The `--javabase` option is set as suggested in this bug report[3]. Coverage has been manually tested with GCC 7 on Ubuntu 18.04. [1]: bazelbuild/bazel#9406 [2]: bazelbuild/bazel#10457 [3]: bazelbuild/bazel#7953
Define configuration options for collecting coverage data with Bazel. The coverage command for Bazel is fairly fragile and many configurations do not work [1,2]. The `--javabase` option is set as suggested in this bug report[3]. Coverage has been manually tested with GCC 7 on Ubuntu 18.04. [1]: bazelbuild/bazel#9406 [2]: bazelbuild/bazel#10457 [3]: bazelbuild/bazel#7953
For anyone else that tries to run coverage on Mac, try putting this in your
Thanks to @ulfjack, it is possible to set the correct prefix size through this argument. It'd be nice to fix this bug in Bazel. |
I'm currently trying to collect coverage data from C++ binaries on MacOS, and it's not generating any .gcda files. When I compile by hand following these instructions then I do get gcda output. That seems to have happened because I was using the wrong |
It bugs me that you have to guess the correct value for |
IIUC, the gcno and gcda files have to be next to each other, which is why Bazel copies them into the same tree; however, matching up the names in shell is not straightforward to do in O(n) time. |
Is there any update on this? I'm still hoping I can get coverage reports on my mac using bazel instead of switching to some other compiler mechanism (as done in the aforementioned link). Thanks for all your work ulfjack...think I've read all of your updates on this since 2018 trying to get a sense of the issues. |
Coverage with gcov:
With a value of 3, the paths end up like this:
bazel-testlogs/cpp/foo_test/_coverage/_bazel_ulfjack/312a82d9f5d7857ee9e5303755329142/sandbox/darwin-sandbox/4/execroot/main/bazel-out/darwin-fastbuild/bin/cpp/_objs/foo_test/main.gcda
The collect-coverage.sh script doesn't allow overriding GCOV_PREFIX_STRIP. I have a patch to not set it if it's already set in the test env. On this machine, I have to set it to 10.
The latest gcov does not support the -i flag
The -i flag is hard-coded in collect_cc_coverage.sh with no override possible.
The gcov log uses lower-case "creating"
The collect_cc_coverage.sh only checks for upper-case "Creating".
The generated output is not in intermediate gcov format as expected by lcov_merger.
Coverage with llvm-profdata (--features=llvm_coverage_map_format):
COVERAGE_GCOV_PATH is set to gcov
This is obviously wrong. It needs to be set to llvm-profdata. However, llvm-profdata is not on the path, and there does not seem to be a way to override the location of gcov. I tried setting GCOV=/path/to/llvm-profdata before calling Bazel, but that had no effect.
The lcov_merger simply copies the .profdata file to coverage.dat
At least this allows users to post-process manually, but it's still unfortunate.
The text was updated successfully, but these errors were encountered: