<br><br><div class="gmail_quote">On Wed, Mar 14, 2012 at 4:38 PM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com">chandlerc@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><div class="gmail_quote">On Wed, Mar 14, 2012 at 4:22 PM, Kostya Serebryany <span dir="ltr"><<a href="mailto:kcc@google.com" target="_blank">kcc@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

[asan] rename class BlackList to FunctionBlackList and move it into a separate file -- we will need the same functionality in ThreadSanitizer</blockquote></div><br></div><div>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.</div>

<div><br></div><div>We already have the ability to mark specific functions as ignored via a function attribute. </div></blockquote><div><br></div><div>For asan, yes. For tsan, no, not yet. </div><div>I was going to suggest to add a function attribute no_thread_safety_analysis (as we did for no_address_safety_analysis).</div>
<div>clang already knows this attribute (it was added for thread-safety annotations), but does not propagate it to LLVM.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>We should be using that and only that mechanism inside of LLVM.</div></blockquote><div><br></div><div>Yea, you are right. </div><div>Let me first add the no_thread_safety_analysis attribute to LLVM and then move the blacklist thing to clang. </div>
<div>Would you suggest where in clang is the best place? </div><div><br></div><div>--kcc </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><br></div><div>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:</div>

<div><br></div><div>1) It separates concerns. LLVM now can be tested without inputs other than the IR.</div><div>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.</div>

<div>3) The frontend is already in the business of exposing user-visible flags.</div><div>4) The frontend knows the un-mangled names of functions, making the syntax of the file (potentially) simpler.</div><div><br></div>
<div>
Thoughts?</div>
</blockquote></div><br>