[Bug other/55354] [asan] by default, the asan run-time should be linked statically, not dynamically

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

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

--- Comment #19 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-11-21 08:40:52 UTC ---
(In reply to comment #18)
> For actual ThreadSanitizer runtime -fPIC -ftls-model=initial-exec causes
> degradation of generated code. Linker emits the same tls access code in all
> cases, but the compiler generates worse code.

-fPIC -ftls-model=initial-exec is by definition almost equivalent to -fPIE, the
only exceptions are:
1) -fPIE code is allowed to assume globally visible symbols aren't interposed
2) if TLS vars are defined locally (or hidden visibility), then local-exec
   model can be used instead of initial-exec (one less dereference)

As for 2), I've explained already that by linking -fPIC code into the
executable if the TLS var is defined in the executable, linker TLS transition
transform all other TLS models (even global and local dynamic) into local-exec,
just might result in some nops or for IE->LE setting of a register to an
immediate and using that register as opposed to just using the immediate in the
%fs: prefixed insn.

And for 1), for the fast path, for any symbols on the fast path that shouldn't
be interposeable and that are defined in libtsan, you should be able to just
use visibility attributes and get the same effect.

-fPIE flag simply isn't usable for a library that is to be used also by shared
libraries.  How do you link -fsanitize=thread shared libraries anyway?  Just
don't link libtsan in for -static-libtsan, and rely on the executable being
linked against it?  Such libraries will fail to link with -Wl,-z,defs ...
Of course, having multiple tsan TLS roots in the same process isn't a good idea
either (which is why I think we can't default to -static-libtsan).