[cfe-dev] clang attributes to disable asan/tsan/msan

[Kostya Serebryany]

Err, maybe just rename the last two (not released)?
no_address_safety was supposed to be used for other tools too, anyway.


On Fri, Feb 22, 2013 at 3:19 PM, Chandler Carruth <chandlerc at google.com>wrote:

> On Fri, Feb 22, 2013 at 3:15 AM, Kostya Serebryany <kcc at google.com> wrote:
>
>> Do we also want to rename the LLVM attributes?
>>
>
> As long as you auto-upgrade the one which got released (address_safety),
> that seems fine to me.
>
>
>>
>> [old] address_safety => sanitize_address
>> [recent] thread_safety => sanitize_thread
>> [recent] uninitialized_checks => sanitize_memory
>>
>> --kcc
>>
>>
>>
>> On Tue, Feb 19, 2013 at 9:13 AM, Chandler Carruth <chandlerc at google.com>wrote:
>>
>>> On Mon, Feb 18, 2013 at 9:10 PM, Kostya Serebryany <kcc at google.com>wrote:
>>>
>>>>
>>>>
>>>>
>>>> On Tue, Feb 19, 2013 at 3:55 AM, Chandler Carruth <chandlerc at google.com
>>>> > wrote:
>>>>
>>>>> On Mon, Feb 18, 2013 at 10:35 AM, Sean Silva <silvas at purdue.edu>wrote:
>>>>>
>>>>>> On Mon, Feb 18, 2013 at 8:31 AM, Kostya Serebryany <kcc at google.com>
>>>>>> wrote:
>>>>>> > Hi,
>>>>>> >
>>>>>> > Clang has two attributes to disable bug detection tools in a given
>>>>>> function:
>>>>>> >
>>>>>> > __attribute__((no_thread_safety_analysis)) disables clang's *static*
>>>>>> > thread-safety analysis.
>>>>>> > (
>>>>>> http://clang.llvm.org/docs/LanguageExtensions.html#thread-safety-annotation-checking
>>>>>> )
>>>>>> >
>>>>>> > __attribute__((no_address_safety_analysis)) disables
>>>>>> AddressSanitizer
>>>>>> > (*dynamic* analysis)
>>>>>> >
>>>>>> http://clang.llvm.org/docs/LanguageExtensions.html#extensions-for-dynamic-analysis
>>>>>> >
>>>>>> > Now we need two more attributes to disable
>>>>>> > ThreadSanitizer (http://clang.llvm.org/docs/ThreadSanitizer.html)
>>>>>> > and MemorySanitizer (
>>>>>> http://clang.llvm.org/docs/MemorySanitizer.html)
>>>>>> >
>>>>>> > For MemorySanitizer I propose
>>>>>> __attribute__((no_uninitialized_checks))
>>>>>> > Objections? Better naming suggestion?
>>>>>> > Maybe __attribute__((no_memory_sanitizer))?
>>>>>> > (We deliberately named no-asan attribute
>>>>>> "no_address_safety_analysis" w/o
>>>>>> > mentioning asan
>>>>>> > in the name to make this attribute usable for other tools, e.g.
>>>>>> SAFECode.
>>>>>> > So,
>>>>>> > we may not want to tie the no-msan attribute to msan)
>>>>>>
>>>>>> It seems to me like it is going to be simpler and more transparent to
>>>>>> have the attribute explicitly mention the sanitizer, e.g.`
>>>>>> __attribute__((no_sanitize("memory")))`; then the user knows exactly
>>>>>> what they are getting (since the name corresponds with the command
>>>>>> line option). If other tools want to use those attributes it's not
>>>>>> hard to look for them.
>>>>>>
>>>>>> It also isn't entirely clear to me that the attribute would have
>>>>>> exactly the same semantics for the sanitizers and some other tool.
>>>>>> AFAIK the term "address safety" has no independent meaning and
>>>>>> basically means "the things that asan checks", so the term "address"
>>>>>> in `__attribute__((no_address_safety_analysis))` is already asan
>>>>>> specific in that regard, and it would be clearer to just say
>>>>>> `no_sanitize("memory")`.
>>>>>>
>>>>>> If we really want the attributes to be tool-agnostic, then they should
>>>>>> describe what the function does that is naughty, e.g.
>>>>>> `__attribute__((reads_unintialized_memory_on_purpose))`, and let the
>>>>>> tool interpret that information and behave appropriately.
>>>>>>
>>>>>
>>>>> This summarizes my feelings exactly.
>>>>>
>>>>> I think that even if we grow a set of attributes that describe the
>>>>> semantic oddity of a function (such as reading uninitialized memory, etc),
>>>>> we would still want an escape hatch to just turn off the sanitizer. And
>>>>> when we do that, we really do want to use the exact same terminology that
>>>>> we use in the flags.
>>>>>
>>>>> I don't think it matters whether its one attribute or N attributes as
>>>>> long as we get some naming consistency. I would propose (for simplicity of
>>>>> implementation mostly):
>>>>>
>>>>> __attribute__((no_sanitize_address))
>>>>> __attribute__((no_sanitize_memory))
>>>>> __attribute__((no_sanitize_thread))
>>>>> __attribute__((no_sanitize_undefined))
>>>>>
>>>>
>>>> I like the simplicity (also because we will have to implement these
>>>> attributes in gcc too).
>>>>
>>>> How about this?
>>>> __attribute__((no_sanitize_address)) is a synonym for
>>>> __attribute__((no_address_safety_analysis)), i.e. disables AddressSanitizer
>>>> checking.
>>>> (or maybe we should just leave no_address_safety_analysis?)
>>>>
>>>> __attribute__((no_sanitize_memory)) disables MemorySanitizer checking,
>>>> but still keeps the instrumentation required to avoid false positives.
>>>>
>>>> __attribute__((no_sanitize_thread)) disables ThreadSanitizer checking
>>>> for plain (non-atomic) loads/stores, but still keeps the instrumentation
>>>> required to avoid false positives.
>>>>
>>>
>>> I like it. I would add all three so that we can update code to be
>>> consistent.
>>>
>>> Keep an eye out for a use case for an all-inclusive 'no_sanitize' that
>>> turns everything off.
>>>
>>>
>>>>
>>>>
>>>> --kcc
>>>>
>>>>
>>>>>  ...
>>>>>
>>>>> This pattern should be easy to remember and understand, and removes a
>>>>> lot of ambiguity of which attribute goes with which sanitizer. It also
>>>>> makes it very clear that these are attributes pertaining to the dynamic
>>>>> analysis toolset, not to any static analysis toolset.
>>>>>
>>>>> Of course, I think we should support the existing attributes for
>>>>> backwards compatibility, at least for several releases.
>>>>>
>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130222/bc7ef76d/attachment.html>