[LLVMdev] asan coverage

[Kostya Serebryany]

What are the symptoms?

On Fri, Nov 15, 2013 at 9:37 AM, Bob Wilson <bob.wilson at apple.com> wrote:
> I’m waiting to see if this fixes the buildbots.  Unfortunately, because they were failing all day, there are a bunch of other regressions that have come up, and I’m still working through them.  It takes quite a while to run a bootstrapped LTO clang build, so it will take a while longer.
>
> I don’t have any other useful information at this point, and I share your puzzlement about how your changes could possibly break the compiler.  My only hypothesis is some sort of memory corruption.
>
> I will keep you posted.
>
> On Nov 14, 2013, at 9:22 PM, Kostya Serebryany <kcc at google.com> wrote:
>
>> Also, when are you planing to "reapply the changes or help debug"?
>>
>> On Fri, Nov 15, 2013 at 9:15 AM, Kostya Serebryany <kcc at google.com> wrote:
>>> On Fri, Nov 15, 2013 at 7:26 AM, Bob Wilson <bob.wilson at apple.com> wrote:
>>>> Hi Kostya,
>>>>
>>>> Thanks for the heads-up on this.  I haven’t had a chance to look into the
>>>> details yet, but it looks like these patches may be breaking our
>>>> bootstrapped LTO build.  Our buildbots have been failing all day, and we’re
>>>> still trying to figure out the problem.  I’m going to speculatively revert
>>>> those changes, since they were the only patches on the buildbot blame list.
>>>> I will either reapply the changes or help debug the problem.
>>>
>>> How could this possibly affect your LTO build?
>>> The option is off by default.
>>> Do you have any details, logs, etc?
>>>
>>>>
>>>> —Bob
>>>>
>>>> On Nov 14, 2013, at 5:42 AM, 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
>>>>
>>>>
>