Re: Out-of-line memory checks

2014-04-21 Thread Konstantin Serebryany
On Mon, Apr 21, 2014 at 7:10 PM, Yuri Gribov 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 because y

Re: Out-of-line memory checks

2014-04-21 Thread Yuri Gribov
> asan may still emit inlined checks for things like 'long double' Is this intentional? How about replacing these with a call to __asan_{load,store}N? -Y -- You received this message because you are subscribed to the Google Groups "address-sanitizer" group. To unsubscribe from this group and s

Re: Out-of-line memory checks

2014-04-21 Thread Konstantin Serebryany
On Mon, Apr 21, 2014 at 3:31 PM, Yuri Gribov 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 1 che

Re: Out-of-line memory checks

2014-04-21 Thread Yuri Gribov
>> 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 1 checks in a function). Right, this may be enough for Clang's

Re: Out-of-line memory checks

2014-04-21 Thread Konstantin Serebryany
On Mon, Apr 21, 2014 at 2:29 PM, Yuri Gribov 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 out-lin

Re: Out-of-line memory checks

2014-04-21 Thread Yuri Gribov
>> 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... -Y -- You received this message because you are subscribed to the Google Grou

Re: Out-of-line memory checks

2014-04-21 Thread Konstantin Serebryany
On Mon, Apr 21, 2014 at 2:01 PM, Yuri Gribov wrote: >>> 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 i

Re: Out-of-line memory checks

2014-04-21 Thread Yuri Gribov
>> 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 -- Yo

Re: Out-of-line memory checks

2014-04-21 Thread Konstantin Serebryany
On Mon, Apr 21, 2014 at 1:03 PM, Yuri Gribov 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 properly. Gener

Re: Out-of-line memory checks

2014-04-21 Thread Yuri Gribov
> 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? > My version lacked the UNLIKELY trick. fixed. Cool, upstream code seems to run really fast now: 16 sec. (vs my 17.8 se

Re: Out-of-line memory checks

2014-04-21 Thread Konstantin Serebryany
On Mon, Apr 21, 2014 at 10:33 AM, Yuri Gribov 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 variants? > > My disas: > > 004cf6a0 <__asan_load8>: >