r198858 - Disable LeakSanitizer in TableGen binaries, see PR18325

[Chandler Carruth]

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

> On Thu, Jan 9, 2014 at 3:57 PM, Chandler Carruth <chandlerc at google.com>wrote:
>
>>
>> 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'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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140109/dfe66a96/attachment.html>