r198858 - Disable LeakSanitizer in TableGen binaries, see PR18325

[Chandler Carruth]

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

> Hard to tell.
> The standalone lsan exists and is tested in llvm (check-lsan).
> On the one hand, we are not planing to use standalone lsan anywhere any
> time soon.
> We are quite satisfied with the performance of asan+lsan and we don't want
> to have a separate build with standalone lsan for things like LLVM or
> Chromium.
> On the other hand, there are already users of standalone lsan (outside of
> llvm community) and they find standalone lsan worth using because they
> can't pay the price of asan slowdown.
>
> If we guard this code with something, I'd prefer it to be a regular macro
> (e.g. LEAK_SANITIZER) rather than __has_feature:
>   1. __has_feature is not supported by GCC (lsan is)
>

I don't understand. GCC can just as easily make '__has_feature(...)' expand
to 1 as any other macro. Unless someone is planning to use LSan with a GCC
host on an LLVM internal binary, this seems like a weak argument.

We also guard ASan stuff with __has_feature and GCC has ASan...

If __has_feature is the right way to do this, we should use that. If it
isn't, I suspect the reasons should not have anything to do with GCC.

  2. in case someone wants to have a standalone lsan via LD_PRELOAD
>

So, we're not talking about disabling all of LSan. Just the ability to turn
LSan off for a single program using a global. I don't really see a problem
with LD_PRELOAD not necessarily working with this one feature -- you could
always just not preload LSan when running that binary?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140109/bf9622cc/attachment.html>