[LLVMdev] asan coverage

[Kostya Serebryany]

On Thu, Feb 13, 2014 at 9:38 PM, Bob Wilson <bob.wilson at apple.com> wrote:

>
> On Feb 12, 2014, at 11:43 PM, Kostya Serebryany <kcc at google.com> wrote:
>
>
>
>
> 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?
>
>
> gcov and llvm-cov are just tools to view the coverage data.
>
> We definitely want llvm-cov to continue to read the gcov-style file
> format, and we also need it to continue to support all the same things as
> gcov (at least the old gcc-4.2 version) for the sake of compatibility. I’m
> suggesting that we add new features to teach it to read the data files
> produced by AsanCoverage and (eventually) the -fprofile-instr-generate data.
>

Ok, I see.
Then my question: will there be any objection if I disentangle AsanCoverage
from ASan and make it a separate LLVM phase with the proper clang driver
support?
Or it will be an unwelcome competition with the planned clang coverage?

Thanks!
--kcc




>
>
>
>>  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/20140217/abd458e3/attachment.html>