search for: asancoverag

...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 ex...

...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 t...

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...

...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 us...

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 f...

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)

...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-b...

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

...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 ca...