Displaying 9 results from an estimated 9 matches for "asancoverage".
2014 Feb 13
2
[LLVMdev] asan coverage
...ny <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 ext...
2014 Feb 13
2
[LLVMdev] asan coverage
...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 to...
2014 Feb 18
2
[LLVMdev] asan coverage
Regarding performance, I've made a simple coverage with counters and
compared it with AsanCoverage.
AsanCoverage produces code like this:
mov 0xe86cce(%rip),%al
test %al,%al
je 48b4a0 # to call __sanitizer_cov
...
callq 4715b0 <__sanitizer_cov>
A simple counter-based thing (which just increments counters and does
nothing else useful) produces this:
incq 0xe719c6(%rip)
The p...
2014 Feb 19
2
[LLVMdev] asan coverage
...ent kinds of instrumentation
> serve different purposes, then I think it would make sense to do both.
>
> On Feb 18, 2014, at 3:13 AM, Kostya Serebryany <kcc at google.com> wrote:
>
> Regarding performance, I've made a simple coverage with counters and
> compared it with AsanCoverage.
>
> AsanCoverage produces code like this:
> mov 0xe86cce(%rip),%al
> test %al,%al
> je 48b4a0 # to call __sanitizer_cov
> ...
> callq 4715b0 <__sanitizer_cov>
>
> A simple counter-based thing (which just increments counters and does
> nothing else use...
2014 Feb 18
2
[LLVMdev] asan coverage
On Feb 17, 2014, at 5:13 AM, Kostya Serebryany <kcc at google.com> wrote:
> 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?
I don’t view it as a competition, but assuming that we both succeed in our plans, LLVM would then end up with two very similar solutions fo...
2013 Nov 14
4
[LLVMdev] asan coverage
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)
2014 Feb 19
2
[LLVMdev] asan coverage
...poses, then I think it would make sense
>>> to do both.
>>>
>>> On Feb 18, 2014, at 3:13 AM, Kostya Serebryany <kcc at google.com> wrote:
>>>
>>> Regarding performance, I've made a simple coverage with counters and
>>> compared it with AsanCoverage.
>>>
>>> AsanCoverage produces code like this:
>>> mov 0xe86cce(%rip),%al
>>> test %al,%al
>>> je 48b4a0 # to call __sanitizer_cov
>>> ...
>>> callq 4715b0 <__sanitizer_cov>
>>>
>>> A simple counter-ba...
2014 Apr 18
4
[LLVMdev] multithreaded performance disaster with -fprofile-instr-generate (contention on profile counters)
On Fri, Apr 18, 2014 at 12:13 AM, Dmitry Vyukov <dvyukov at google.com> wrote:
> Hi,
>
> This is long thread, so I will combine several comments into single email.
>
>
> >> - 8-bit per-thread counters, dumping into central counters on overflow.
> >The overflow will happen very quickly with 8bit counter.
>
> Yes, but it reduces contention by 256x (a thread
2014 Apr 23
4
[LLVMdev] multithreaded performance disaster with -fprofile-instr-generate (contention on profile counters)
...t; Will this accuracy be enough for the major use cases?
>
> Moreover, this approach allows to implement the counter increment using a callback:
> if ((fast_thread_local_rand() & counter) == 0) __cov_increment(&counter);
> which in turn will let us use the same hack as in AsanCoverage: use the PC to map the counter to the source code.
> (= no need to create separate section in the objects).
>
> Thoughts?
>
> —kcc
I can see that the behavior of our current instrumentation is going to be a problem for the kinds of applications that you’re looking at. If you can...