r198858 - Disable LeakSanitizer in TableGen binaries, see PR18325

[Chandler Carruth]

On Thu, Jan 9, 2014 at 3:50 AM, Kostya Serebryany <kcc at google.com> wrote:

> We currently don't have any macro that is used to enable lsan in llvm
> bootstrap.
> We can easily add one, no problem, and then put this code under #ifdef
> LEAK_SANITIZER
> It would make things a bit more ugly.
>
> We have tow problems to solve wrt lsan and bootstrap:
> 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).
> 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 is nice. I don't have to solve this general problem though for
> the asan+lsan bootstrap bot.
>

I would have some macro (or __has_feature) which is enabled by any flagset
that links the lsan runtime library. That way the preprocessor test can be
independent of which other sanitizers are enabled, but we can still guard
the use of this extension.


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).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140109/c388d878/attachment.html>