Replies: 2 comments
-
If branch coverage is important to you - note that I just corrected the llvm-profdata discussion, above. (Thank you, Alan Phipps) |
Beta Was this translation helpful? Give feedback.
0 replies
-
I should also mention that the LLVM-profile use model seems to produce some other odd artifacts when writing an LCOV-format output file (
For these cases, see |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
There have been a couple of recent llvm-related issues and/or questions - so maybe it is a good time to mention a few points.
If you are using clang/llvm, then there are a least two coverage use models which are supported by the tools.
(The description below uses elipsis (
...
) to stand in for other options and flags that you need to pass to the various tools.)gcov model: LLVM can generate gcov-format data - just like gcc
clang --coverage -o myfile.o -c myfile.c ...
# pass --coverage flag to instrument during compilationclang --coverage -o myexe myfile.o myotherfile.o ...
# pass --coverage to link coverage-enabled executable(you can link both coverage-instrumented and non-instrumented code into the same executable. In that case: you will get coverage data only for the instrumented files.
./myexe ...
# run tests and generate coverage dataYou can use GCOV_PREFIX and GCOV_PREFIX_STRIP to write the runtime data to some non-default location
use
llvm-cov gcov myfile.gcda ...
to extract gcov format data from the .gcda/.gcno files for your code.Note that this is exactly the same thing that you would do for gcc via
gcov myfile.gcda ...
- except that you are using the llvm toolchain componentllvm-cov
.If you like living dangerously, then you can use a gcc/4.X version of
gcov
rather thanllvm-cov
to process your data. This will very likely work.you can tell
lcov
(orgeninfo
) to use llvm-cov using the--gcov-tool
flag to pass the name of the executable ("llvm-cov") and the options ("gcov"):lcov --capture -o mydata.info -d . --gcov-tool llvm-cov --gcov-tool gcov ....
Note that
--gcov-tool
appears twice: once to name the tool, once to pass a tool option. See the lcov man page for more information.At this point: you have an lcov-format .info file - and can proceed to generate a HTML report, merge it with other data, or whatever.
llvm profile model: use LLVM profile data directly:
clang -fprofile-instr-generate -fcoverage-mapping -o myfile.o -c myfile.c ...
clang -fprofile-instr-generate -fcoverage-mapping -o myexe myfile.o myotherfile.o ....
./myexe ...
# run tests and generate coverage dataYou can use LLVM_PROFILE_FILE to write runtime data to some non-default location.
llvm-profdata merge -sparse *.profraw -o mydata.profdata
# transform .profraw files.llvm-cov export -format=lcov --instr-profile mydata.profdata myexe > mydata.info
# generate lcov format directlyllvm-cov export -format=lcov --instr-profile mydata.profdata myexe1 --object myext2 --object ... > myCombinedData.info
Or capture data for each executable, then aggregate.
If your LLVM is older than that - then there will be no branch information in the generated .info file
the llvm profile use model is described more fully here.
Modified Condition / Decision Coverage with LLVM (MC/DC metrics):
man genhtml
for details, and see the examples in.../tests/lcov/mcdc
.llvm2lcov
translator, and need to follow the use model described here (and/or seellvm2lcov --help
).Note that neither the 'gcov model' nor the 'profile model' described above support MC/DC metrics.
I hope that someone finds this useful.
Henry
PS: interesting experiment: generate a coverage report for your project using GCC - then generate another using LLVM. Compare them (differential report).
Beta Was this translation helpful? Give feedback.
All reactions