From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25961 invoked by alias); 18 May 2010 14:22:54 -0000 Received: (qmail 25905 invoked by uid 48); 18 May 2010 14:22:41 -0000 Date: Tue, 18 May 2010 14:22:00 -0000 Message-ID: <20100518142241.25904.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug target/44139] Exporting emutls symbols from a DLL broken on w32 targets In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "ktietz at gcc dot gnu dot org" 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: 2010-05/txt/msg01921.txt.bz2 ------- Comment #11 from ktietz at gcc dot gnu dot org 2010-05-18 14:22 ------- (In reply to comment #10) > Re-opening. It turns out that GCC fails to actually apply the dllexport > attribute to TLS control vars. So solving the binutils problem allows > auto-export of a TLS variable to work, but as auto-export gets disabled in the > presence of any explicit dllexport directives, this isn't an effective > solution. I believe the problem needs to be addressed in > config/i386/winnt.c#i386_pe_encode_section_info() > I have doubts about the approach in winnt.c, but well maybe I am wrong here. I investigated for this issue and see the real issue in declaration cloning in varasm.c's emutls_decl- function, which simply doesn't copy attributes of the delaration, which then leads to issues about name-decoration. Also the DECL_DLLIMPORT_P has to be copied here, too (for import). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44139