sanitizer-coverage vs asan_blacklist

[Timur Iskhodzhanov]

Filed https://code.google.com/p/chromium/issues/detail?id=484711

вт, 28 апр. 2015 г. в 22:54, Reid Kleckner <rnk at google.com>:

> On Tue, Apr 28, 2015 at 10:48 AM, Alexey Samsonov <vonosmas at gmail.com>
> wrote:
>
>>
>> On Tue, Apr 28, 2015 at 10:23 AM, Timur Iskhodzhanov <timurrrr at google.com
>> > wrote:
>>
>>>
>>>
>>> вт, 28 апр. 2015 г. в 20:03, Alexey Samsonov <vonosmas at gmail.com>:
>>>
>>>> On Sat, Apr 11, 2015 at 8:38 PM, Alexey Samsonov <vonosmas at gmail.com>
>>>> wrote:
>>>>
>>>>>
>>>>> On Sat, Apr 11, 2015 at 2:36 PM, Timur Iskhodzhanov <
>>>>> timurrrr at google.com> wrote:
>>>>>
>>>>>> __attribute__((no_instrumentation)) ?  Sounds like a perfect fit for
>>>>>> the job
>>>>>>
>>>>>
>>>>> However, IIRC, Clang folks wanted positive attributes
>>>>> ("sanitize_address", "sanitize_memory" etc.) on LLVM
>>>>> functions, not sure "no_instrumentation" will be accepted. Otherwise
>>>>> we will have to emit "sanitize_coverage"
>>>>> attribute on all functions that need to be instrumented, and that
>>>>> would be somewhat unfortunate.
>>>>>
>>>>
>>>> So, essentially you need an attribute to disable coverage
>>>> instrumentation of a particular function
>>>> (as ASan instrumentation is already disabled), right?
>>>>
>>>
>>> Yes, or...
>>> What I really want is a way to tell the compiler "hey, I don't want this
>>> function to do any memory accesses other than those required by its code".
>>> Do you think we should maybe have an attribute for exactly this purpose?
>>>
>>
>> Oh, so this would be not really relevant to sanitizers. This attribute
>> makes sense, but... how would you enforce it? It will have to be supported
>> by
>> all sanitizers, coverage instrumentation, profiling, and maybe even
>> optimization passes.
>>
>
> Yeah, I don't know how we would quantify "memory accesses except those
> required by the code". Does this attribute ban load speculation, where I
> hoist the load to known addressable memory out of a loop?
>
> I think taking the boring path of adding no_sanitize_coverage to clang and
> sanitize_coverage to LLVM is probably the best, most straightforward thing
> to do, even if it's not the least work.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150505/7cf7a9e4/attachment.html>