r198858 - Disable LeakSanitizer in TableGen binaries, see PR18325

[Kostya Serebryany]

On Thu, Jan 9, 2014 at 4:03 PM, Chandler Carruth <chandlerc at google.com>wrote:

>
> 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?
>

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)
  2. in case someone wants to have a standalone lsan via LD_PRELOAD

--kcc
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140109/e3dda6c5/attachment.html>