http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59061
--- Comment #11 from Kostya Serebryany <kcc at gcc dot gnu.org> --- > > 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. I did not expect you to say "yes" :) Build system is a mess. But having two build systems is more mess. Also, the test system for libsanitizer in gcc is much weaker than in clang. We have no tests for tsan/lsan in gcc and don't have newer lit-style tests for asan (we tend to use more lit-style tests nowadays). This is not a huge issue since the sources are the same, but hidden build system differences may actually break things w/o us noticing. > > > > 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? Yes. > 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.? Sergey, please answer here (and make sure this is documented)
