[LLVMdev] LCOV per commit

[Joshua Cranmer]

On 5/6/2015 2:47 PM, Sylvestre Ledru wrote:
> Le 06/05/2015 21:05, Renato Golin a écrit :
>> On 6 May 2015 at 19:15, Sanjoy Das <sanjoy at playingwithpointers.com> wrote:
>>> I could not easily locate this on http://llvm.org/reports/coverage/ so
>>> asking here:  what workload is the coverage computed over?  IOW, what
>>> all does the bot run to get this coverage information?
>> Nothing is clear in that page. No revision number, no arch, no test
>> names, nothing. Just a date.
> I am running it.
> I don't have access to test names but I can try to add the revision number.
> The arch is GNU/Linux 64 bit.
>
> Joshua (as cc) worked on bringing better coverage to Thunderbird and
> Firefox:
> https://github.com/jcranmer/mozilla-coverage
> Maybe I could hack with his tool to get the test information to
> LLVM/Clang too.
> For now, I haven't put too much effort into it as I wasn't sure how many
> people
> are using the code coverage (btw, is it possible to have stats on our
> website?)

An example of the tool I wrote is publicly accessible at 
<https://www.tjhsst.edu/~jcranmer/m-ccov/>, although it is a bit on the 
older side. I essentially ported lcov to Python, firstly since the lcov 
tool seemed to suddenly run achingly slowly, and speed is important when 
you're merging 100 test coverage files comprising ~1.8M counters. I also 
added a coverage treemap overview 
(<https://www.tjhsst.edu/~jcranmer/m-ccov/coverage.html?dir=js> is a 
link that won't kill your browser in animation), and you can view 
detailed code coverage of individual tests on individual files, a 
feature LCOV didn't have when I poked it.

The only reason the tooling doesn't support clang is because clang's 
code coverage support was fatally broken when I started the project, 
necessitating the need to use gcc for tests. The automated 
infrastructure for building Firefox is presently using a sufficiently 
old version of clang on OS X that the inability to get an instrumented 
version of Firefox on the automation infrastructure is probably due to 
inherently broken code coverage, and I've lacked any way to definitively 
debug the issue, so it ended up being a lower priority.

-- 
Joshua Cranmer
Thunderbird module owner
DXR coauthor