r198858 - Disable LeakSanitizer in TableGen binaries, see PR18325

[Alp Toker]

On 09/01/2014 12:03, Chandler Carruth wrote:
>
> On Thu, Jan 9, 2014 at 4:01 AM, Kostya Serebryany <kcc at google.com 
> <mailto:kcc at google.com>> wrote:
>
>     On Thu, Jan 9, 2014 at 3:57 PM, Chandler Carruth
>     <chandlerc at google.com <mailto:chandlerc at google.com>> wrote:
>
>
>         On Thu, Jan 9, 2014 at 3:50 AM, Kostya Serebryany
>         <kcc at google.com <mailto: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?

Who controls / defines the interface?

This looks like a spectacular thinko rather than being something 
intentional -- is it possible to fix it to drop one or more underscores 
instead of devising workarounds?

There's never a valid reason to require user code to define reserved 
names (although it's sometimes OK for user code to _use_ reserved names).

I'm heading out for a couple of hours, please gate this behind a macro 
or revert until a resolution is found.

Thanks
Alp.


-- 
http://www.nuanti.com
the browser experts