[Bug sanitizer/59061] Port leaksanitizer

["kcc at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061

--- Comment #18 from Kostya Serebryany <kcc at gcc dot gnu.org> ---
(In reply to Joost VandeVondele from comment #17)
> (In reply to Sergey Matveev from comment #16)
> > 
> > Under the current behavior -fsanitize=address,leak is equivalent to
> > -fsanitize=address.
> > 
> > We've considered other options, such as making -fsanitize=leak change the
> > default run-time behavior (currently the ASan runtime always has leak
> > detection runtime-disabled by default, whereas the standalone LSan runtime
> > always has it enabled). But we never arrived at anything sensible.
> 
> From my 'user perspective' it would be great if -fsanitize=leak would
> perform leak checking by default (i.e. remove the requirement to export
> ASAN_OPTIONS="detect_leaks=1"). 

That's what -fsanitize=leak does in clang. 

> At that point it would be natural to expect that -fsanitize=address,leak
> just enables the leak checking by default, while -fsanitize=address might
> not.

That's not so trivial to implement and I don't like anything non-trivial :)
The trivial solution is to have lsan on by default in asan -- we are working 
on that. 

> 
> Out of curiosity, is there a runtime performance difference in using -llsan
> or -lasan for leak checking only ?

I don't think we've measured pure-lsan slowdown, but I expect it to be small.
asan/lsan bring in a different allocator (malloc/free).
We tried to make it very fast and our measurements show that's it is close to 
tcmalloc performance (but a bit more greedy in memory).
It also performs stack unwind on every malloc, so on malloc-intensive apps
you may see some small slowdown.