[llvm-commits] [llvm] r152753 - in /llvm/trunk/lib/Transforms/Instrumentation: AddressSanitizer.cpp CMakeLists.txt FunctionBlackList.cpp FunctionBlackList.h

Kostya Serebryany kcc at google.com
Wed Mar 14 16:47:50 PDT 2012


On Wed, Mar 14, 2012 at 4:38 PM, Chandler Carruth <chandlerc at google.com>wrote:

> On Wed, Mar 14, 2012 at 4:22 PM, Kostya Serebryany <kcc at google.com> wrote:
>
>> [asan] rename class BlackList to FunctionBlackList and move it into a
>> separate file -- we will need the same functionality in ThreadSanitizer
>
>
> If you are going to be hacking on this, I would like to propose a
> significant cleanup to its design. This is especially relevant as it moves
> to be a more general feature.
>
> We already have the ability to mark specific functions as ignored via a
> function attribute.
>

For asan, yes. For tsan, no, not yet.
I was going to suggest to add a function
attribute no_thread_safety_analysis (as we did
for no_address_safety_analysis).
clang already knows this attribute (it was added for thread-safety
annotations), but does not propagate it to LLVM.



> We should be using that and only that mechanism inside of LLVM.
>

Yea, you are right.
Let me first add the no_thread_safety_analysis attribute to LLVM and then
move the blacklist thing to clang.
Would you suggest where in clang is the best place?

--kcc



>
> I think the way to support the blacklist file is to do it in the frontend
> (Clang in this case), where it loads the file, and applies the
> attribute(s?) to the matching functions while emitting LLVM IR. This has
> several advantages in my might, let me know what you think about them:
>
> 1) It separates concerns. LLVM now can be tested without inputs other than
> the IR.
> 2) The frontend is already in the business of finding random files on the
> users' machines which are not directly related to the source file.
> 3) The frontend is already in the business of exposing user-visible flags.
> 4) The frontend knows the un-mangled names of functions, making the syntax
> of the file (potentially) simpler.
>
> Thoughts?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20120314/4998d67a/attachment.html>


More information about the llvm-commits mailing list