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
> 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
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
>> 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
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
>> 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
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
>> 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
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
> 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
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>:
>
11 matches
Mail list logo