[Bug sanitizer/59061] Port leaksanitizer

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Kostya Serebryany from comment #7)
> > > Clang supports -fsanitize=leak which simply links a standalone lsan library
> > > (no instrumentation at compile time required). 
> > > Perhaps gcc can add such option too. 
> > 
> > I agree that such an option would be useful (see also below).
> 
> I am not an expert in the gcc build system so this will have to be done by
> someone else. Also, I am heavily frightened by the amount of differences 
> between the clang and gcc builds of libsanitizer. On my...
> The only good solution I see will hardly be accepted by the gcc community
> (which is: export compiler-rt as is, with all of its build and test system,
> anything else is going to increase the maintenance cost).

No way, we really don't want to bring all those extra dependencies on
prerequisites, completely different (and IMNSHO very ugly) build system etc.

> > For now, I put '-fsanitize=address' for the link step only, which has the
> > same effect. 
> 
> It has a bit different effect because asan's allocator has greater memory
> footprint compared to a plain lsan's allocator. 
> But -fsanitize=leak as a separate entity is not on top of our priorities.
> It works, but we don't test it on anything large. 

So, do you link for -fsanitize=address -lasan and for -fsanitize=leak -llsan
instead?  Easily doable of course, but we should create liblsan as shared
library in that case too.  What combination of those do you allow?  I mean, is
-fsanitize=address,leak allowed (and only links -lasan?), etc.?