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

["dvyukov at google dot com" <gcc-bugzilla@gcc.gnu.org>]

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