[LLVMdev] asan coverage

[Kostya Serebryany]

On Thu, Feb 13, 2014 at 11:10 AM, Bob Wilson <bob.wilson at apple.com> wrote:

>
> On Feb 12, 2014, at 10:31 AM, Kostya Serebryany <kcc at google.com> wrote:
>
> Hi,
>
> Justin is making nice commits for llvm-cov, so I thought we may continue
> this discussion now.
> The quick-and-dirty implementation of coverage (in asan) is getting some
> early users and they seem to be happy.
> AsanCoverage allows to collect per-function or per-basic-block coverage
> (booleans only, no counters) at a very low cost:
> 1% for per-function and 20% for per-basic-block:
> https://code.google.com/p/address-sanitizer/wiki/AsanCoverage
> The output format is very simple and does not require any external tool
> (other than 56 lines in python) to handle it.
> So, I was wondering it some similar functionality could be included as
> part of llvm-cov effort.
> Also, do you have some documentation about the llvm-cov (how it works,
> what is the performance, etc)?
>
>
> Our recent work on llvm-cov has been pretty limited in scope. We’ve gotten
> it to work as a drop-in replacement for the old version of gcov that we had
> from gcc-4.2. There are still a few minor differences, but it generally
> seems to be working well.
>
> As we discussed at the dev meeting, I want to hook up our PGO
> instrumentation to be used for coverage as well, but so far, our focus has
> been on the PGO side and there is nothing implemented for coverage yet.
> Once we start on that, I plan to extend llvm-cov to be the command line
> interface for viewing the coverage data. If you would like to teach it to
> display the AsanCoverage data as well, that seems like a good idea.
>

I'd rather prefer to have functionality similar to today's AsanCoverage in
the main "LLVM coverage", whatever that is.


> Just be careful not to break anything for the old-style gcov support.
>

Hm. Is that the long term goal?
My impression was that gcov is broken by design and beyond repair and we
wanted something new that can scale.
Or you are talking only about the gcov file format which we want to keep
for legacy reasons even if the files will be generated somehow differently?


> There are various coverage tools out there that wrap around gcov, and we
> need to be careful not to break them.
>
>
> BTW, would a 5-minute lightning talk about AsanCoverage be interesting at
> LLVM Euro 2014?
>
>
> I’d be interested in that, but I haven’t been involved at all with
> planning LLVM Euro, so someone else will have to answer that.
>

I'll send a proposal.

--kcc

>
>
> Thanks,
>
> --kcc
>
>
> On Thu, Nov 14, 2013 at 5:42 PM, Kostya Serebryany <kcc at google.com> wrote:
>
>> Bob, Justin,
>>
>> I've just committed a poor man's coverage implementation that works with
>> asan.
>> http://llvm.org/viewvc/llvm-project?rev=194701&view=rev
>> http://llvm.org/viewvc/llvm-project?rev=194702&view=rev
>> It provides only function-level boolean coverage (i.e. no counters, just
>> "visited or not"),
>> but is very fast and very simple (no extra sections to the binary file,
>> etc)
>> I've tried it for Chrome's content_shell (huge and heavy binary) and the
>> overhead
>> is negligible at both run-time and shutdown-time.
>>
>> We'll be evaluating this implementation and collecting usage stats.
>> Maybe we want to implement something simple like this in the Clang
>> coverage.
>>
>> --kcc
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140213/56598057/attachment.html>