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).
