From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28413 invoked by alias); 21 Nov 2012 09:06:37 -0000 Received: (qmail 26060 invoked by uid 48); 21 Nov 2012 09:04:17 -0000 From: "dvyukov at google dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug other/55354] [asan] by default, the asan run-time should be linked statically, not dynamically Date: Wed, 21 Nov 2012 09:06:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: other X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: dvyukov at google dot com X-Bugzilla-Status: RESOLVED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2012-11/txt/msg02012.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55354 --- Comment #20 from Dmitry Vyukov 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).