Re-attaching updated implementation just in case.
On Mon, Apr 21, 2014 at 10:33 AM, Yuri Gribov tetra2...@gmail.com wrote:
So even though my implementation is slightly faster we're still
getting a 70% perf hit.
interesting.
can you show the assembly (objdump -d) for __asan_load8 in both
On Mon, Apr 21, 2014 at 1:03 PM, Yuri Gribov tetra2...@gmail.com wrote:
You call __asan_report_load8 directly.
This will only work if __asan_load8 does not have its own frame.
You mean you don't want asan callbacks to be present in stacktraces?
That too, but we also need to be able to unwind
BTW note that we will suffer significant PLT penalty in sanitized shared
libs.
Don't use shared libs :)
I don't ;) - it's all about the users.
Solution here is obvious - throw in another static lib that would get
linked into DSOs. But this would complicate driver of course.
-Y
--
You
On Mon, Apr 21, 2014 at 2:29 PM, Yuri Gribov tetra2...@gmail.com wrote:
Solution here is obvious - throw in another static lib that would get
linked into DSOs. But this would complicate driver of course.
immensely
GCC with it's default dynamic runtime would suffer quite a bit...
Only if the
On Mon, Apr 21, 2014 at 3:31 PM, Yuri Gribov tetra2...@gmail.com wrote:
GCC with it's default dynamic runtime would suffer quite a bit...
Only if the out-line calls will be used (in clang, this is a
workaround for a bad compile-time, we'll use out-line functions only
when there are more than
On Mon, Apr 21, 2014 at 7:10 PM, Yuri Gribov tetra2...@gmail.com wrote:
asan may still emit inlined checks for things like 'long double'
Is this intentional?
Just not done yet.
How about replacing these with a call to
__asan_{load,store}N?
Yep.
--kcc
-Y
--
You received this message
I wonder where such big difference is coming from. I'll examine perf
when I finally get my hands on SPEC2006.
You don't need SPEC, just run something small like bzip2.
Ok, good to know. Here are my results for bunzipping a vmtouched 100M file:
gcc:
0m6.315s
clang:
0m5.570s
clang
Meanwhile we've made the first step for Out-of-line memory checks.
http://llvm.org/viewvc/llvm-project?view=revisionrevision=206387 and
http://llvm.org/viewvc/llvm-project?view=revisionrevision=206383
introduce a new hidden flag -mllvm
-asan-instrumentation-with-call-threshold=N which will use
470.lbm, 5.85, 3.00, 0.51
482.sphinx3, 3.55, 2.02, 0.57
--kcc
On Thu, Apr 17, 2014 at 12:45 PM, Konstantin Serebryany
konstantin.s.serebry...@gmail.com wrote:
Meanwhile we've made the first step for Out-of-line memory checks.
http
Meanwhile we've made the first step for Out-of-line memory checks.
Looks like an effort duplication, I've been working on this for the
last couple of days.
btw, I've run SPEC (test data, C only) and it shows that out-of-line
instrumentation is 2x slower.
I wonder whether this is due to PLT
On Thu, Apr 17, 2014 at 3:36 PM, Yuri Gribov tetra2...@gmail.com wrote:
Meanwhile we've made the first step for Out-of-line memory checks.
Looks like an effort duplication, I've been working on this for the
last couple of days.
Sorry.
btw, I've run SPEC (test data, C only) and it shows
btw, I've run SPEC (test data, C only) and it shows that out-of-line
instrumentation is 2x slower.
I wonder whether this is due to PLT redirection.
clang uses static asan-rt by default, no PLT.
Agreed, this will only matter for sanitized shared libraries.
I wonder where such big
On Thu, Apr 17, 2014 at 4:56 PM, Yuri Gribov tetra2...@gmail.com wrote:
btw, I've run SPEC (test data, C only) and it shows that out-of-line
instrumentation is 2x slower.
I wonder whether this is due to PLT redirection.
clang uses static asan-rt by default, no PLT.
Agreed, this
I don't think there are an short term plans for that. We can not use
clang to compile linux kernel yet.
It could be an interesting experiment.
On Fri, Mar 28, 2014 at 8:44 PM, Yuri Gribov tetra2...@gmail.com wrote:
All,
I was wondering whether there are plans to add (optional) out-of-line
That will add some more complexity to the build system.
E.g. __asan_read1co will have to reside in a separate library.
Yup.
You probably want to implement them in hand-written assembly, because
otherwise we'll get the same bad code generated by the same compiler.
Sure, that goes w/o saying.
All,
I was wondering whether there are plans to add (optional) out-of-line
instrumentation of memory accesses i.e. use function calls like
__asan_read1 instead of explicit instruction sequence to access shadow
memory? AFAIK KernelSanitizer is already using this approach.
Memory savings would be
16 matches
Mail list logo
