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

[Chandler Carruth]

On Fri, Feb 22, 2013 at 3:25 AM, Kostya Serebryany <kcc at google.com> wrote:

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

I don't feel particularly strongly about this, but personally I would
rename them all rather than mess with trying to support some other tool
that isn't part of the primary llvm tree with this attribute.

Especially with the advent of textual attributes, it becomes much easier
for these types of projects to set up their own attribute that can have
whatever semantics or support story they want.

But really, whatever you're comfortable with at this stage. We can always
change our minds later about attributes in the IR as long as we provide
continued support for old bitcode files.


>
>
> 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/9c9374e2/attachment.html>