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

login
register
mail settings
Submitter Holger Blasum
Date Nov. 8, 2010, 2:28 p.m.
Message ID <20101108142812.GA9556@laptop-hbl.localdomain>
Download mbox | patch
Permalink /patch/70421/
State New
Headers show

Comments

Holger Blasum - Nov. 8, 2010, 2:28 p.m.
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,
Ralf Wildenhues - Nov. 8, 2010, 7:09 p.m.
Hello Holger,

here's a syntactic-only review:

* Holger Blasum wrote on Mon, Nov 08, 2010 at 03:28:12PM CET:
> --- 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 

Trailing white space; several instances.

> +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. 

@math{2^{64}}, otherwise only the 6 is superscripted.

> +Overflow usually can be ruled out by ascertaining that coverage
> +run time times CPU speed is less than @math{2^64}.

likewise

> +@node Multithreaded Programs
> +@section Collecting Coverage Data of Multithreaded Programs 

A new section needs to appear in some menu, no?

> +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 

Two spaces after end-of-sentence period; several instances.

> +@command{gcov} will not be faithful in multithreaded programs. If, 
> +during compilation, the additional option @samp{-fprofile-whole-graph} 

@option{-fprofile-whole-graph}

> +is specified then @command{gcov} will use a representation of 

comma after specified

> +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

Cheers,
Ralf

Patch

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