From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31525 invoked by alias); 21 Nov 2012 08:43:38 -0000 Received: (qmail 28766 invoked by uid 48); 21 Nov 2012 08:41:06 -0000 From: "jakub at gcc dot gnu.org" 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 08:43: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: jakub at gcc dot gnu.org 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/msg02011.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55354 --- Comment #19 from Jakub Jelinek 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).