r198858 - Disable LeakSanitizer in TableGen binaries, see PR18325

[Kostya Serebryany]

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.

--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).
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140109/fe403772/attachment.html>