On Thu, Jan 9, 2014 at 3:57 PM, Chandler Carruth <[email protected]>wrote:
> > On Thu, Jan 9, 2014 at 3:50 AM, Kostya Serebryany <[email protected]> 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's not trivial because lsan could be used as a link-time-only feature (or even as LD_PRELOAD-ed library), so there is not way to distinguish at compile time if lsan will be present. --kcc > 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). >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
