On Thu, Jan 9, 2014 at 4:01 AM, Kostya Serebryany <[email protected]> wrote:
> 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. > I understand that, but the question is -- do you think that usage pattern will be prevalent? Is it worth putting an external definition in the binary *always* just to catch the case where we do a link-time-only flag? Put another way, is it really too burdensome to say that LSan does require a compile time flag in order to support some usage patterns?
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
