[cfe-dev] clang attributes to disable asan/tsan/msan
chandlerc at google.com
Mon Feb 18 21:13:42 PST 2013
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>
>>> > Hi,
>>> > Clang has two attributes to disable bug detection tools in a given
>>> > __attribute__((no_thread_safety_analysis)) disables clang's *static*
>>> > thread-safety analysis.
>>> > (
>>> > __attribute__((no_address_safety_analysis)) disables AddressSanitizer
>>> > (*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"
>>> > mentioning asan
>>> > in the name to make this attribute usable for other tools, e.g.
>>> > 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
>>> 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):
> 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
> (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
Keep an eye out for a use case for an all-inclusive 'no_sanitize' that
turns everything off.
>> 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...
More information about the cfe-dev