With gcov, is it possible to merge to .gcda files?

Question

I have the same source files (C and Obj-C) being compiled into two targets: the unit test executable and the actual product (which then gets integration tested). The two targets build into different places, so the object files, .gcno and .gcda files are separate. Not all source files are compiled into the unit test, so not all objects will exist there. All source files are compiled into the product build.

Is there a way to combine the two sets of .gcda files to get the total coverage for unit tests and integration tests (as they are run on the product build)?

I'm using lcov.

Mac OS X 10.6, GCC 4.0

Thanks!

Saros

Answer 1

Since you're using lcov, you should be able to convert the gcov .gcda files into lcov files and merge them with lcov --add-tracefile.

From manpage: Add contents of tracefile. Specify several tracefiles using the -a switch to combine the coverage data contained in these files by adding up execution counts for matching test and filename combinations.

Jhvh

Answer 2

Finally I managed to solve my problem by means of lcov.

Basically what I did is the following:

• Compile the application with the flags -fprofile-arcs -ftest-coverage --coverage
• Distribute the copy of the application to each node.
• Execute the application in each node in parallel. (This step generates into the application directory in the access host the coverage information)
• Let lcov make his work:
  • lcov --directory src/ --capture --output-file coverage_reports/app.info
• Generate the html output:
  • genhtml -o coverage_reports/ coverage_reports/app.info

I hope this can be of help to someone.

Hamm

Wow, thanks for replying. I've had 2 very different jobs between asking that question and now. I hope this does help someone. – Saros

--coverage is a synonym for -fprofile-arcs -ftest-coverage (when compiling) and -lgcov (when linking), so using all of them is redundant. – Sauger

I do not understand how this should work. Does this mean that gcov locks the files when two processes try to write to the same gcda? Can this be confirmed? – Randell

Answer 3

See UPDATE below.

I think the intended way to do this is not to combine the .gcda files directly but to create independent coverage data files using

lcov -o unittests.coverage -c -d unittests
lcov -o integrationtests.coverage -c -d integrationtests

Each coverage data then represents one "run". You can of course create separate graphs or html views. But you can also combine the data using --add-tracefile, -a for short

lcov -o total.coverage -a unittests.coverage -a integrationtests.coverage

From the total.coverage you can generate the total report, using genhtml for example.

UPDATE: I found that it is actually possible to merge .gcda files directly using gcov-tool, which unfortunately are not easily available on the Mac, so this update doesn't answer the original question.

But with gcov-tool you can even incrementally merge many set together into one:

gcov-tool merge dir1 dir -o dir
gcov-tool merge dir2 dir -o dir
gcov-tool merge dir3 dir -o dir

Although that is not documented and might be risky to rely on.

This is really fast and avoids the round-about way over lcov, which is much slower when merging many sets. Merging some 80 sets of 70 files takes under .5 second on my machine. And you can still do an lcov on the aggregated set, which also is very much faster, should you need it. I use Emacs cov-mode which uses the .gcov files directly.

See this answer for details.

Chou

Answer 4

I merge it by lcov multi -d parameters as below. It works.

lcov -c -d ./tmp/ -d ./tmp1/ -o ./tmp/coverage.info

Thinskinned

This is what I was looking for. No need to create intermediate .info files, just collate all gcda. I create separate gcda for each test to be able to run them in parallel (e.g. with 'make -j test'). – Chou

Answer 5

A simpler alternative would be to compile shared C/ObjC files once (generating .o files or better yet, single .a static library) and later linked into each test. In that case gcov will automatically merge results into single .gcno/.gcda pair (beware that tests have to be run serially, to avoid races when accessing gcov files).

Wed