branches within C++ destructors (gcov)

Rohit Gupta rohit.guptakec@gmail.com
Thu Feb 25 11:58:00 GMT 2010


Hi ,
Also in the gcov branch coverage we have something like at end of code :-

------------------------------------

function __static_initialization_and_destruction_0(int, int) called 1 returned 100% blocks executed 100%
function global constructors keyed to main called 1 returned 100% blocks executed 100%
         3:   54:}
branch  0 taken 100% (fallthrough)
branch  1 taken 0%
branch  2 taken 100% (fallthrough)
branch  3 taken 0%
call    4 returned 100%
------------------------------------------------


It is not the part of actual code, why do we have it and what its 
significance in terms of branches . Can we omit it from the coverage??

Thanks,
ROHIT


On 02/18/2010 08:14 PM, Axel Freyn wrote:
> Hi,
>
> On Thu, Feb 18, 2010 at 03:52:28PM +0530, Rohit Gupta wrote:
>    
>> [...]
>> I am having problem understanding branches ( number ) generated by
>> gcov  report for c++ program. Might you please clear my doubts.
>>      
> I fear there is no such possibility, as
> http://gcc.gnu.org/onlinedocs/gcc/Invoking-Gcov.html states:
>
> "There can be multiple branches and calls listed for a single source
> line if there are multiple basic blocks that end on that line. In this
> case, the branches and calls are each given a number."
>
> and
>
> "There is no simple way to map these branches and calls back to source
> constructs. In general, though, the lowest numbered branch or call will
> correspond to the leftmost construct on the source line. "
>
>
> In addition, the compiler seems to use its internal representation to
> define the "calls" and "branches", e.g. at the end of main gcov states:
>
>    
>> function __static_initialization_and_destruction_0(int, int) called 1 returned 100% blocks executed 100%
>> function global constructors keyed to main called 1 returned 100% blocks executed 100%
>>          3:   54:}
>>      
> thus calling two functions which you never called (but which are called
> by the system). So I think, in order to fully understand the output of gcov,
> you would have to look at the internal way how the compiler constructs
> the code.
>
> HTH,
>
> Axel
>
>
>    



More information about the Gcc-help mailing list