On Thu, Jan 9, 2014 at 4:12 AM, Kostya Serebryany <[email protected]> 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?
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
