X-Recipient: archive-cygwin AT delorie DOT com DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type:content-transfer-encoding; q=dns; s=default; b=jZCpO/hjJ5yZiaJloO4LSchpINpIXLQI/09uBzGyCPx wUU+hjgX8FoiBQpd984jB4vsX6pcXIo8BbxJYcjYcxasEQ4xZk11TZhoLjsg6TGS cE88LfEyPeLRWAndFJoS8cn7S6vtzK3xgIFTc/0zVlaBkFsI6g0PJDnmRsJiBffc = DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type:content-transfer-encoding; s=default; bh=AxCKL1+y+AWQfQUpA1qbAfjEAmI=; b=Y43r622IokBgOTb1b 5DxP6hey2MMAMhj6Vkx6vmrKyD2f3l7IWue0gam3Etc2yDpcoOFW2GfjbpwamZ/u BX+tCbLpdyCLvOkzIk5B7YFQchL7M8C5OAHhHRF7Lo3eupFYMCVI8D/kLGHsyWng /KVpGagWPD3BSc3JOI3THI1dhk= Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=sk:__emutl, annual X-HELO: mail-wm0-f53.google.com X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-transfer-encoding; bh=gslW11wxsdC9ZKRU/3egIwzfyjUaCgKsNz3zwMPdD1Y=; b=et6rMEpeF1lfs9NP8FC7wa9SGfztBhZdTdKTTA75sscrTrXteHECq3+OBW7E50hKK6 K6yMkQjCmcllmGPSKRcrOQ+WvQ5bdx/6tJueuVrnOrA4MVKaUewe4Z/OeQKTkbavD46H z5e2MJfO/mNO6KLq2Vd+Ic9F14DNKv/4T3WJ66g+EYJjYVDKAh8s4/JNI+utyfH7Imi7 D1jdUq9mElMn1hGz2tet5693wXCIers43HXla1zLMV/u+wPi0vu/GeIixqgl2lBjZY05 xZ2PFXeVDpuXbA1Nc4vtl0DFOZdPe6RW3oaiJn+lxI1ip8hjXhj3CHYBRi81bZRAc7mz jYuw== X-Gm-Message-State: AIkVDXJLZh7iNGxDY9PN+0qu30HQGx7qI575JVrfMWG8fIQvbLv88Cpipc2Vs2qqwMCyhbt6oOSPGQ7SJknf0g== X-Received: by 10.223.170.3 with SMTP id p3mr20351514wrd.100.1485336368529; Wed, 25 Jan 2017 01:26:08 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References:

From: =?UTF-8?Q?V=C3=A1clav_Haisman?= Date: Wed, 25 Jan 2017 10:26:07 +0100 Message-ID: Subject: Re: C++11 thread_local implementation issue on Cygwin/AMD64 To: cygwin AT cygwin DOT com Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id v0P9RRjI026549 On 9 February 2016 at 15:23, Václav Haisman wrote: > On 19 May 2015 at 10:52, Václav Haisman wrote: >> On 19 January 2015 at 15:42, Václav Haisman wrote: >>> >>> Hi. >>> >>> I have hit an issue with thread-local storage variables on >>> Cygwin/AMD64, I do not see it with Cygwin/i686. >>> >>> I am having linking issues when using `thread_local` keyword in Cygwin >>> with its GCC 4.8.3 and GCC 4.9.2. This is derived from log4cplus. The >>> test case is split into three files: >>> >>> File def.hxx: >>> >>> ~~~~ >>> #include >>> >>> namespace N >>> { >>> struct S { std::string str; }; >>> // extern declaration in a header >>> extern thread_local S * ptd; >>> >>> // accessing the extern declared ptd here >>> inline >>> S * get_ptd () >>> { >>> if (! ptd) >>> ptd = new S; >>> return ptd; >>> } >>> } // namespace N >>> ~~~~ >>> >>> File def.cxx: >>> >>> ~~~~ >>> #include "def.hxx" >>> >>> namespace N >>> { >>> // definition of ptd >>> thread_local S * ptd = nullptr; >>> } // namespace N >>> ~~~ >>> >>> File use.cxx: >>> >>> ~~~~ >>> #include "def.hxx" >>> >>> namespace N >>> { >>> __declspec(dllexport) >>> void * foo () >>> { >>> // invoking inline get_ptd() function to get the value in ptd >>> return get_ptd (); >>> } >>> } >>> ~~~~ >>> >>> Now, when I compile each .cxx with `g++ -std=gnu++11 >>> -fvisibility=hidden -c use.cxx def.cxx` and then try to link with `g++ >>> -shared -o cygtest.dll use.o def.o`, I get the following error from >>> linker: >>> >>> ~~~~ >>> use.o:use.cxx:(.text$_ZTWN1N3ptdE[_ZTWN1N3ptdE]+0x15): relocation >>> truncated to fit: R_X86_64_PC32 against undefined symbol `TLS init >>> function for N::ptd' >>> collect2: error: ld returned 1 exit status >>> ~~~~ >>> >>> The nm -C ./def.o output confirms that: >>> >>> ~~~~ >>> `--> nm -C ./def.o >>> 0000000000000000 b .bss >>> 0000000000000000 d .data >>> 0000000000000000 r .rdata >>> 0000000000000000 r .rdata$zzz >>> 0000000000000000 t .text >>> 0000000000000008 r __emutls_t._ZN1N3ptdE >>> 0000000000000000 D __emutls_v._ZN1N3ptdE >>> 0000000000000000 r std::piecewise_construct >>> ~~~~ >>> >>> As you can see, the ptd thread-local variable initialization function >>> is not defined anywhere. The use.o references this initialization >>> function (see bottom of the listing): >>> >>> ~~~~ >>> `--> nm -C ./use.o >>> 0000000000000000 b .bss >>> 0000000000000000 d .data >>> 0000000000000000 i .drectve >>> 0000000000000000 p .pdata >>> 0000000000000000 p .pdata$_ZN1N1SC1Ev >>> 0000000000000000 p .pdata$_ZN1N7get_ptdEv >>> 0000000000000000 p .pdata$_ZTWN1N3ptdE >>> 0000000000000000 r .rdata >>> 0000000000000000 r .rdata$.refptr.__emutls_v._ZN1N3ptdE >>> 0000000000000000 r .rdata$.refptr._ZTHN1N3ptdE >>> 0000000000000000 r .rdata$zzz >>> 0000000000000000 R .refptr.__emutls_v._ZN1N3ptdE >>> 0000000000000000 R .refptr._ZTHN1N3ptdE >>> 0000000000000000 t .text >>> 0000000000000000 t .text$_ZN1N1SC1Ev >>> 0000000000000000 t .text$_ZN1N7get_ptdEv >>> 0000000000000000 t .text$_ZTWN1N3ptdE >>> 0000000000000000 A .weak._ZTHN1N3ptdE._ZN1N1SC1Ev >>> 0000000000000000 r .xdata >>> 0000000000000000 r .xdata$_ZN1N1SC1Ev >>> 0000000000000000 r .xdata$_ZN1N7get_ptdEv >>> 0000000000000000 r .xdata$_ZTWN1N3ptdE >>> U __emutls_get_address >>> U __emutls_v._ZN1N3ptdE >>> U __gxx_personality_seh0 >>> U __real__ZdlPv >>> U __real__Znwm >>> U _Unwind_Resume >>> U operator delete(void*) >>> 0000000000000000 T N::S::S() >>> 0000000000000000 T N::foo() >>> 0000000000000000 T N::get_ptd() >>> U std::basic_string, >>> std::allocator >::basic_string() >>> U operator new(unsigned long) >>> 0000000000000000 r std::piecewise_construct >>> w TLS init function for N::ptd >>> 0000000000000000 T TLS wrapper function for N::ptd >>> ~~~~ >>> >>> Now, this code seems to work well on Linux with both GCC and Clang. >>> >>> Is this a GCC problem on Cygwin? >>> Am I using extern thread_local wrong? >>> >>> My experiments show that not using the extern keyword seems to fix the >>> issue. But I am not sure if that does not introduce two ptd >>> thread-local variables in two TUs. >>> >>> See also http://stackoverflow.com/q/28023728/341065 >> >> >> This is also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64697. > > Annual ping. :) Annual ping for 2017. :) -- VH -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple