I use gcov for doing code coverage analysis with lcov for generating graphical output of coverage. This works well for code file where atleast some part of object file has been executed. I want to be able to track files which have not been executed at all. I suspect this has to do with .gcda files not being generated for these files. Is there a way to force the generation of .gcda file for all object files irrespective of execution?
The procedure to do this is outlined here:
http://linux.die.net/man/1/lcov
Recommended procedure when capturing data for a test case:
create baseline coverage data file
lcov -c -i -d appdir -o app_base.info
perform test
appdir/test
create test coverage data file
lcov -c -d appdir -o app_test.info
combine baseline and test coverage data
lcov -a app_base.info -a app_test.info -o app_total.info
For all of your files that are correctly compiled and linked, there will be a .gcda file. If you see that there's a missing *.gcda file check to see if the *.gcno file exists. If it doesn't check to see if all of you Makefiles are correctly build with:
-ftest-coverage : The .gcno notes file is generated when the source file is compiled with this
-fprofile-arcs : .gcda count data file is generated when a program containing object files built with the GCC -fprofile-arcs option is executed.
More info on: https://gcc.gnu.org/onlinedocs/gcc/Gcov.html#Gcov
Related
How do I include non-test targets in bazel coverage? Currently I use the following bazel command to get code coverage:
bazel coverage \
--instrument_test_targets \
--experimental_cc_coverage \
--combined_report=lcov \
//... --test_arg=--logtostderr
The project is written in C++. The command works fine. However, the output lcov trace file only includes the files that have coverage. If a C file does not have a test, it is not in the lcov trace file.
Does bazel coverage only executes the test targets? Is there a way to include all targets (the non-test targets)? So that even if a file has no test, I can still see it in the report (the report will show zero coverage). The intention for this is that if someone adds new files and doesn't write unit test, the file can be shown in coverage report.
Can you reproduce using --incompatible_cc_coverage?
Using gcc 8.2.0, and given a coverage run, with files called myfile.cov.gcda and myfile.cov.gcno, how do I extract line coverage data for myfile.cc on the command line?
I'm going to have multiple .gcda files in my project. One for each test case. Because gcov will merge .gcda for each test case execution, I move each .gcda file to a different directory.
When calling gcov, I tried to specify .gcda (.\data\gcda\evenodd.gcda) and .gcno (.\data\gcno\evenodd.gcno) files.
I used -o data\ but it seems that gcov doesn't scan the path subdirectories.
Then, I tried to specify each file's path like this:
gcov -o data\gcno\evenodd.gcno data\gcda\evenodd.gcda evenodd.c
because I thought it would accept more than one path. Alas, the result is :
By putting the .gcda path first instead of .gcno, this is what I got:
Since the default location of these files is in the source file directory, I tried to put .gcno there and then specify .gcda path. It didn't work.
Based on those results, gcov won't receive more than one path for -o.
Apparently gcov will always look for .gcno and .gcda in pair when -o is specified. Is there a way to do this other than putting both of them in the same directory?
You should not move .gcno/.gcda files to different folder after generation because gcov will not be able to locate related source files. Moreover, gcov has to be run in exact same directory where test executable has been compiled.
We found that for some of our Github branches that are automatically pulled into Jenkins, gcovr does not generate any coverage information. It claims that no files are found and returns a code coverage of 0%.
Other branches work fine. Once we pull the code into master, gcovr can generate code coverage files for the very same code.
This happens because gcov creates files that hold the entire path, e.g. #usr#include#boost#numeric#conversion#detail#converter.hpp.gcov. If the branch name is part of Jenkins' workspace path, a long branch name may kick some of these generated file names over the filesystem's maximum file name length.
To fix this, set gcov to hash the filenames and run gcovr in two passes:
gcovr -r `pwd` --gcov-executable="gcov -s `pwd` -x" -k
gcovr -r `pwd` --gcov-executable="gcov -s `pwd` -x" -g --html --html-details -o coverage/index.html
When i build my project for coverage testing with "--coverage -fprofile-arcs -ftest-coverage", and then move the build and source to the other user directory to execute testing. I will get so many problems such as "xxx/cc/cc/getopt_log.c:cannot open source file"
the details as the below:
Processing cs/CMakeFiles/cfa/__/src/base/fault_injection.c.gcda
/home/cov/build/xfcq/src/base/fault_injection.c:cannot open source file
the path of "/home/cov/build/xfcq/src/base/fault_injection.c" is the path of build environment, how to change it as the relative path or the path I specified.
I tried to use GCOV_PREFIX and GCOV_PREFIX_STRIP, these can't work well for me.
I also tried to add -b option for lcov, it does not also work well for me.
e.g., lcov --gcov-tool=/bin/gcov -d . -b xx/src -t "xfcq" -o test_cov.info
do you have idea to resolve it?
Well for using gcov coverage process you should never move the files after building your project, instead you should modify your automated build scripts to build everything to the desired location.
When you compile your project with the specified options it generates *.gcno files for each source file which are necessarily the flow chart like details of the relevant source file.
So, the object files are instrumented in such a way that they should trigger function(added by compiler to generate coverage info ) whenever any line of statement is executed to generate *.gcda files with all the execution information.
Note: I can see that you have specified three options in question (--coverage -fprofile-arcs -ftest-coverage) which is again wrong, as --coverage works as a replacement to the other two.
If you specify only --coverage then it will do for the compilation and the linking too.(remember to use it at both the places positively though)