<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Jan 9, 2014 at 3:57 PM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank">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 dir="ltr"><div class="gmail_extra"><div class="im"><br><div class="gmail_quote">On Thu, Jan 9, 2014 at 3:50 AM, 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"><div>We currently don't have any macro that is used to enable lsan in llvm bootstrap. </div><div>We can easily add one, no problem, and then put this code under #ifdef LEAK_SANITIZER</div>


<div>It would make things a bit more ugly.</div><div><br></div><div>We have tow problems to solve wrt lsan and bootstrap: </div><div>1. Make asan+lsan bootstrap clean. This is what I need to solve now to enable leak checking for the entire llvm. For this we may also use #if __has_feature(address_sanitizer). </div>


<div>2. Make any+lsan bootstrap clean ("any" is one of asan, tsan, msan, <none>). This may introduce more complexity and that is why the current solution <span style="font-family:arial,sans-serif;font-size:13px">is nice. I don't have to solve this general problem though for the asan+lsan bootstrap bot. </span></div>

</blockquote></div><br></div>I would have some macro (or __has_feature) which is enabled by any flagset that links the lsan runtime library.</div></div></blockquote><div><br></div><div>That's not trivial because lsan could be used as a link-time-only feature (or even as LD_PRELOAD-ed library), </div>
<div>so there is not way to distinguish at compile time if lsan will be present. </div><div><br></div><div>--kcc </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"> That way the preprocessor test can be independent of which other sanitizers are enabled, but we can still guard the use of this extension.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">However, I'll note that the real benefit of doing this is to not define this external symbol when we don't need it. We don't actually isolate ourselves from any usage of reserved names, because we of course have to test for the feature or the macro *using a reserved name*. That's kinda the point of reserved names and trying to pick them in a way that makes collisions extremely unlikely. But __has_feature is at least likely to DTRT even if it does collide (it is likely to expand to 0 for a feature it doesn't know about).</div>

</div>
</blockquote></div><br></div></div>