Displaying 6 results from an estimated 6 matches for "__sanitizer_cov".
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 performance is more or less the same, although the issue with false
sharing still remains
(http://lists.cs.uiuc.edu/piperm...
2014 Feb 19
2
[LLVMdev] asan coverage
...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 useful) produces this:
> incq 0xe719c6(%rip)
>
> The performance is more or less the same, although the issue with false
> sharing stil...
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
2014 Feb 19
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 performance is more o...
2016 Mar 19
2
Should we enable -Wrange-loop-analysis? (Was: [llvm] r261524 - Fix some abuse of auto...)
...=========================================================
> --- llvm/trunk/tools/sancov/sancov.cc (original)
> +++ llvm/trunk/tools/sancov/sancov.cc Mon Feb 22 07:11:58 2016
> @@ -364,7 +364,7 @@ static void getObjectCoveragePoints(cons
> if (SanCovAddrs.empty())
> Fail("__sanitizer_cov* functions not found");
>
> - for (const auto Section : O.sections()) {
> + for (object::SectionRef Section : O.sections()) {
> if (Section.isVirtual() || !Section.isText()) // llvm-objdump does the same.
> continue;
> uint64_t SectionAddr = Section.getAd...
2015 Nov 12
3
Inexplicable ASAN report. Code generation bug?
I'm struggling to explain an ASAN report I'm now getting that I didn't
get previously on the same code. In fact the report only happens with
-O2 and not when I remove the -O flags which makes it hard to debug
and makes me suspect it's dependent on exactly which instructions the
code generation decides to access the bytes involved. Afaict the C
code shouldn't be accessing the