Hello Didier, On Sat, Sep 19, 2009 at 09:04:54PM +0200, Didier Ptitjes wrote: > GTest forks the test process in order to test for asserting tests. > Looking at the reports of lcov, it looks like there is absolutely no > information gathered about the child processes. ... > I already have seen this question asked two times on gcc-help but none > got a real answer: > http://gcc.gnu.org/ml/gcc-help/2009-07/msg00334.html > http://gcc.gnu.org/ml/gcc/2008-09/msg00490.html Hmm, I have no quick idea how to fix your problem, but it might be helpful to understand where it occurs (then one can think of a work-around): basically the gcov tools work in a way (1) that enabling -ftest-coverage will result in a different binary than the binary without -ftest-coverage (1.4.1 in [1]), this gives you *.gcno files (2) when the instrumented binary it is run you have a data collection (1.4.2 in [1]) phase where the binary adds up counters in memory whenever passing through C sequence points and then you have a reporting phase where the memory data is dumped into *.gcda files. (3) then there is a reporting phase (1.4.3 in [1]) where that *.gcda and *.gcno files are converted into *.gcov files The first thing to divide and conquer this would be to test and report * whether after the phase (1) all *.gcno files are built for both parent and child, * whether after the phase (2) all *.gcda files are built/modified for parent and child. [1] http://sysrun.haifa.il.ibm.com/hrl/greps2007/papers/gcov-on-an-embedded-system.pdf HTH, -- Holger Blasum (SYSGO AG)
