How to interpret the format of lcov output file?

[abitrolly]

What does each line of the lcov output file mean?

TN:
SF:xxxx
FN: 2,func
....
FNF:3
FNH:2
BRDA:127,1,0,204
....
BRF:10
....
DA:122,148
....
LF:19
LH:13
end_of_record

---

This is a repost of linux-test-project/ltp#113 by @benquike

[henry2cox]

Easiest way to figure it out is to look at the parse code. There are some (moderately readable?) comments in the ‘lcovutil.pm’ library (in my version of lcov). TN: test name SF: source file path FN: line number,function name FNF: number functions found FNH: number hit BRDA: branch data: line, block, (expressions,count)+ BRF: branches found DA: line number, hit count LF: lines found LH: lines hit. Henry

[abitrolly]

So the format is per test, right? Like the same source file path can be included multiple times for different tests?

[henry2cox]

Right. This is how you get to the ‘per testcase’ views from genhtml, for example. (Note, though, that the source code view, various of the date/author binning tables, etc – are all computed from the combined coverage over all the testcases.) Henry

[abitrolly]

Where is this lcovutil.pm? I don't see it in this repository.

Is there the date/author info in the LCOV output? I found some files from 2015 and there isn't https://dev-builds.libreoffice.org/lcov_reports/master-2015-06-10_23.49.39/UnoControls/source/base/basecontrol.cxx.gcov.html

[henry2cox]

My fork: https://github.com/henry2cox/lcov/tree/diffcov_initial, then “./lib/lcovutil.pm”. This version implements a lot of new features compared to base lcov. Those enhancements are (mostly) described in the corresponding pull request. If you are specifically interested in the .info file syntax, then please note that this code treats branch coverage expressions slightly differently than base lcov (…because we enhanced things to handle Verilog code; the main bits of the Verilog implementation are not in this repo). Henry

[henry2cox]

I'm in the process of trying to clean up the issue list.
In view of the age of this issue, and because I think that this one is answered - and so will close it now.
Note that the code discussed above (lcovutil.pm, date/owner binning, Verilog support, etc) - has been merged to TOT.

Please reopen this issue if you feel that something is missing.
Thanks
Henry

[abitrolly]

Although I would appreciate a formal versioned specification of the format, which can be answer more questions for people who are not able to read the Perl code, I see no reasons to keep this issue open.

[gohar94]

Is the format at the bottom of the page helpful? https://ltp.sourceforge.net/coverage/lcov/geninfo.1.php

[abitrolly]

@gohar94 not really.

1. It is hard to find
2. It needs clarifications and can not be edited
3. It needs extension

Questions not answered.

1. What is .da file?
2. How sections are delimited? Full list of sections is missing.
3. What is gcc block and number for the branch?
4. How to trace coverage of several branches in one line?
5. How checksum is calculated?
6. What does "instrumented lines" mean?
7. What is .bb file?

Extensions needed.

1. Absolute paths are non-portable, need to be relative to project root
2. Need an example what is branch

[henry2cox]

FWIW:

• the comment that @gohar94 pointed to is actually the geninfo man page - which is editable (.../man/geninfo.1).
  Feel free to update as you like and submit a pull request.
  (That's the great thing about an opensource project...you can fix it and everyone can benefit.)

• With respect to absolute vs relative paths: lcov is actually merely recording what it finds in the compiler's generated data. The paths are determined by your build environment (compiler command line). There are some lcov features you can use to turn absolute paths into relative ones (see '--prefix' and '--substitute') and to turn relative ones into absolute ('--substitute').
  Worst case: the format is ASCII - and 'sed' is your friend.

• checksum is md5_base64 (but is really not relevant as long as it is consistently generated during 'capture').
  Also see "--version-script" - which you can use to compute whatever hash code you prefer. Probably the best ideas is to use attributes that are relevant to your revision control system.

• some of your other questions are probably best answered by 'gcov' documentation (and/or by reading the gcc and/or llvm code). (But don't expect miracles and don't expect absolute clarity. Coverage seems to be a bit of an afterthought, in all toolchains/all projects, everywhere.)

[abitrolly]

some of your other questions are probably best answered by 'gcov' documentation (and/or by reading the gcc and/or llvm code).

@henry2cox that's why it is a bad specification of the format.