This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gcov: option to instrument whole basic block graph, no use of spanning tree optimization


Dear all, 

I'm impressed about the amount of previous work here, summing up :-)

If I understand correctly Andi's suggestion (as well as 
    http://gcc.gnu.org/ml/gcc-patches/2002-01/msg00195.html ) 
would be most beautiful to some but not be portable to arbitrary 
embedded architectures. 

If I understand correctlty Zdenek's pointer to 
    http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00950.html
some middle ground concerning portability versus accuracy could perhaps 
also be gained by making the counter incrementation atomic - but again 
at the price of portability (and modulo the comment of Andi).

My own self-interest for submitting this patch basically is to get some 
degree of feedback if the approach proposed by the patch is sound 
(I have not heard anything to the contrary yet, but would be very 
interested if any objection arises).
With limited resources I fear the current patch is all I can offer 
for the moment (+ a small patch for gcc/doc/gcov.texi, which I hope
does not make any incorrect claims, attached).

In defense of the -fprofile-whole-graph suggestion (of course, I don't 
care about the name) I would stress that the most useful result of test 
coverage often simply is whether coverage is zero or non-zero (in 
that case one is not really interested in the exact non-zero values). 
Applying it is completely orthogonal to implementing more 
sophisticated approaches (possibly available on less 
architectures) later. 

Regards,

-- 
Holger
Index: gcc/doc/gcov.texi
===================================================================
--- gcc/doc/gcov.texi	(revision 166172)
+++ gcc/doc/gcov.texi	(working copy)
@@ -512,6 +512,32 @@
 coverage of all the uses of the inline function will be shown for the
 same source lines, the line counts themselves might seem inconsistent.
 
+@node Overflow
+@section Counter Overflow 
+Counters are implemented as a 64-bit value which means that overflow 
+would occur only after @math{2^64} times of stepping through a program path. 
+Overflow usually can be ruled out by ascertaining that coverage
+run time times CPU speed is less than @math{2^64}.
+
+@node Multithreaded Programs
+@section Collecting Coverage Data of Multithreaded Programs 
+As the implementation of threads and context switching depends on 
+the operational environment, it is hard to implement a truly portable 
+coverage for multithreaded programs at the compiler level. So 
+@command{gcov} will not be faithful in multithreaded programs. If, 
+during compilation, the additional option @samp{-fprofile-whole-graph} 
+is specified then @command{gcov} will use a representation of 
+the whole basic block graph instead of the otherwise optimal
+spanning tree optimization. That means that the compiled program 
+will use more memory but is more robust than when the spanning tree
+optimization is used. In the absence of counter overflow that 
+implies that coverage in multithreaded programs is conservatively 
+estimated: it may be underreported but in particular this option 
+ensures that a non-zero coverage value means that the path has been 
+taken and conversely that if a path has been taken the coverage value 
+is non-zero. (This property still can be useful if one wants test 
+coverage.) 
+
 @c man end
 
 @node Gcov Data Files

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]