llvm dev - Jun 2014 - [LLVMdev] Unifying TSan blacklist and no_sanitize_thread

On Fri, May 30, 2014 at 1:53 AM, Evgeniy Stepanov <eugeni.stepanov at
gmail.com
> wrote:
> On Fri, May 30, 2014 at 12:41 AM, Alexey Samsonov <vonosmas at
gmail.com>
> wrote:
> > Hi,
> >
> > I consider reducing the usage of blacklist in sanitizer
instrumentation
> > passes and doing the necessary work in frontend (Clang) instead.
> >
> > Some of it is already implemented: e.g. Clang will attach an attribute
> > "sanitize_address" to function definition only if this
function is not
> > blacklisted. In this case we won't instrument the memory accesses
in this
> > function in ASan instrumentation pass, so there's no need to
looking at
> > blacklist once again.
> >
> > TSan pass does the following:
> >
> > 1) instruments plain memory accesses
> > 2) instruments atomic accesses
> > 3) instruments memory intrinsics calls.
> > 4) adds function entry/exit callbacks.
> >
> > If a function doesn't have sanitize_thread attribute (e.g. it was
> annotated
> > with __attribute__((no_sanitize_thread)) ), then it still does (2),
(3)
> and
> > (4). If a function is blacklisted,
> > TSan pass does nothing. Shouldn't the behavior be the same? I
think, we
> must
> > always do (4) to get
> > good stack traces, and probably do (2) (we may report races on atomics
in
> > this case, but otherwise
> > we may miss synchronization). Thoughts?
>
> I don't think we should do (2).
>
> Sounds like your plan would let us drop blacklist from *SanitizerPass
> arguments, right? That's great.
>
Yes. We can already do that for TSan and MSan - sanitize_memory and
sanitize_thread
attrs are not added to functions by Clang if the functions are blacklisted.
There's still some
stuff to do in ASan w.r.t. global variables.

BTW, are we still interested in having "-mllvm -msan-blacklist" and
"-mllvm
-tsan-blacklist",
or we may kill these flags as well, and rely only on a frontend Clang
compiler flag?

>
>
> >
> > --
> > Alexey Samsonov
> > vonosmas at gmail.com
>


-- 
Alexey Samsonov
vonosmas at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140530/385b0ac5/attachment.html>

Now that the blacklist implementation has been moved to the frontend, will
there be any change in behavior w.r.t. name mangling? Previously only the
mangled names were matched against the blacklist. I think it makes more
sense to use the demangled names, or both.


On Sat, May 31, 2014 at 4:23 AM, Alexey Samsonov <vonosmas at gmail.com>
wrote:
>
> On Fri, May 30, 2014 at 1:53 AM, Evgeniy Stepanov <
> eugeni.stepanov at gmail.com> wrote:
>
>> On Fri, May 30, 2014 at 12:41 AM, Alexey Samsonov <vonosmas at
gmail.com>
>> wrote:
>> > Hi,
>> >
>> > I consider reducing the usage of blacklist in sanitizer
instrumentation
>> > passes and doing the necessary work in frontend (Clang) instead.
>> >
>> > Some of it is already implemented: e.g. Clang will attach an
attribute
>> > "sanitize_address" to function definition only if this
function is not
>> > blacklisted. In this case we won't instrument the memory
accesses in
>> this
>> > function in ASan instrumentation pass, so there's no need to
looking at
>> > blacklist once again.
>> >
>> > TSan pass does the following:
>> >
>> > 1) instruments plain memory accesses
>> > 2) instruments atomic accesses
>> > 3) instruments memory intrinsics calls.
>> > 4) adds function entry/exit callbacks.
>> >
>> > If a function doesn't have sanitize_thread attribute (e.g. it
was
>> annotated
>> > with __attribute__((no_sanitize_thread)) ), then it still does
(2), (3)
>> and
>> > (4). If a function is blacklisted,
>> > TSan pass does nothing. Shouldn't the behavior be the same? I
think, we
>> must
>> > always do (4) to get
>> > good stack traces, and probably do (2) (we may report races on
atomics
>> in
>> > this case, but otherwise
>> > we may miss synchronization). Thoughts?
>>
>> I don't think we should do (2).
>>
>> Sounds like your plan would let us drop blacklist from *SanitizerPass
>> arguments, right? That's great.
>>
>
> Yes. We can already do that for TSan and MSan - sanitize_memory and
> sanitize_thread
> attrs are not added to functions by Clang if the functions are
> blacklisted. There's still some
> stuff to do in ASan w.r.t. global variables.
>
> BTW, are we still interested in having "-mllvm -msan-blacklist"
and
> "-mllvm -tsan-blacklist",
> or we may kill these flags as well, and rely only on a frontend Clang
> compiler flag?
>
>
>>
>>
>> >
>> > --
>> > Alexey Samsonov
>> > vonosmas at gmail.com
>>
>
>
>
> --
> Alexey Samsonov
> vonosmas at gmail.com
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140603/da7402ad/attachment.html>

On Tue, Jun 3, 2014 at 4:33 AM, Sergey Matveev <earthdok at google.com>
wrote:
> Now that the blacklist implementation has been moved to the frontend, will
> there be any change in behavior w.r.t. name mangling? Previously only the
> mangled names were matched against the blacklist. I think it makes more
> sense to use the demangled names, or both.
>
Yes, we will be able to match unmangled (and, hopefully, fully-qualified)
names from the blacklist. But first we need to match the correct source
file names (which we should get from Clang's SourceManager) instead of LLVM
module identifiers, which can be arbitrary.

>
>
> On Sat, May 31, 2014 at 4:23 AM, Alexey Samsonov <vonosmas at
gmail.com>
> wrote:
>
>>
>> On Fri, May 30, 2014 at 1:53 AM, Evgeniy Stepanov <
>> eugeni.stepanov at gmail.com> wrote:
>>
>>> On Fri, May 30, 2014 at 12:41 AM, Alexey Samsonov <vonosmas at
gmail.com>
>>> wrote:
>>> > Hi,
>>> >
>>> > I consider reducing the usage of blacklist in sanitizer
instrumentation
>>> > passes and doing the necessary work in frontend (Clang)
instead.
>>> >
>>> > Some of it is already implemented: e.g. Clang will attach an
attribute
>>> > "sanitize_address" to function definition only if
this function is not
>>> > blacklisted. In this case we won't instrument the memory
accesses in
>>> this
>>> > function in ASan instrumentation pass, so there's no need
to looking at
>>> > blacklist once again.
>>> >
>>> > TSan pass does the following:
>>> >
>>> > 1) instruments plain memory accesses
>>> > 2) instruments atomic accesses
>>> > 3) instruments memory intrinsics calls.
>>> > 4) adds function entry/exit callbacks.
>>> >
>>> > If a function doesn't have sanitize_thread attribute (e.g.
it was
>>> annotated
>>> > with __attribute__((no_sanitize_thread)) ), then it still does
(2),
>>> (3) and
>>> > (4). If a function is blacklisted,
>>> > TSan pass does nothing. Shouldn't the behavior be the
same? I think,
>>> we must
>>> > always do (4) to get
>>> > good stack traces, and probably do (2) (we may report races on
atomics
>>> in
>>> > this case, but otherwise
>>> > we may miss synchronization). Thoughts?
>>>
>>> I don't think we should do (2).
>>>
>>> Sounds like your plan would let us drop blacklist from
*SanitizerPass
>>> arguments, right? That's great.
>>>
>>
>> Yes. We can already do that for TSan and MSan - sanitize_memory and
>> sanitize_thread
>> attrs are not added to functions by Clang if the functions are
>> blacklisted. There's still some
>> stuff to do in ASan w.r.t. global variables.
>>
>> BTW, are we still interested in having "-mllvm
-msan-blacklist" and
>> "-mllvm -tsan-blacklist",
>> or we may kill these flags as well, and rely only on a frontend Clang
>> compiler flag?
>>
>>
>>>
>>>
>>> >
>>> > --
>>> > Alexey Samsonov
>>> > vonosmas at gmail.com
>>>
>>
>>
>>
>> --
>> Alexey Samsonov
>> vonosmas at gmail.com
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
>> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>>
>>
>

-- 
Alexey Samsonov
vonosmas at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140604/db978bba/attachment.html>