http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55354
--- Comment #20 from Dmitry Vyukov <dvyukov at google dot com> 2012-11-21 09:04:07 UTC --- (In reply to comment #19) > (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) What I see is that it also affect code generation (register allocation). Do we need to file a bug on that? > 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? Yes, we rely on the library being linked into the executable, because we want the runtime be linked statically. For dynamic libraries that are loaded into a non-instrumented executable (e.g. swig so preloaded into python process), we statically link the tsan runtime into the so. > 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).
