sanitizer-coverage vs asan_blacklist

[Reid Kleckner]

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/20150428/ec23767d/attachment.html>