[PATCH] ignore --disable-free in clang when leak detection is enabled

[Chandler Carruth]

A few thoughts about this -- I'm not yet totally happy with a compile-time
check here...

On Thu, Dec 26, 2013 at 5:39 AM, Kostya Serebryany <kcc at google.com> wrote:

> Hi chandlerc, dblaikie,
>
> Disobey --disable-free flag if LEAK_SANITIZER macro is defined, for
> PR18320.
> This way the build for LeakSanitizer will need to use
> -DCMAKE_CXX_FLAGS=-DLEAK_SANITIZER
>
> Alternatives:
> 1. use #if __has_feature(address_sanitizer). This will solve our immediate
> need
> to make asan+lsan bootstrap clean, but will not allow to run lsan-only
> (w/o asan).
>

Yea, this doesn't make sense for me. Especially as lsan doesn't require any
instrumentation at all.


>
> 2. Check if we have lsan at run-time instead of build time.
> This may actually be nicer, but the only good way to do that that I know of
> is to use weak functions, which will require more ifdefs.
>

I think this, or some variant of this, is probably the right strategy.

My suggestion would be a bit different. I would do something along the
lines of making the allocations which --disable-free interacts with not
appear to be "leaks" by placing their pointers into a global root somehow.
I would rather be able to run LSan both with and without --disable-free and
catch leaks either way.

Thoughts on that?

It seems like we could come up with a pointer-stashing strategy that would
be well below the noise floor to avoid impacting performance?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131226/e716402a/attachment.html>