From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 920 invoked by alias); 25 Jan 2017 09:26:43 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 868 invoked by uid 89); 25 Jan 2017 09:26:42 -0000 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 Received: from mail-wm0-f53.google.com (HELO mail-wm0-f53.google.com) (74.125.82.53) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 25 Jan 2017 09:26:13 +0000 Received: by mail-wm0-f53.google.com with SMTP id r144so19732805wme.1 for ; Wed, 25 Jan 2017 01:26:11 -0800 (PST) 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 Received: by 10.80.186.81 with HTTP; Wed, 25 Jan 2017 01:26:07 -0800 (PST) In-Reply-To: References: From: =?UTF-8?Q?V=C3=A1clav_Haisman?= Date: Wed, 25 Jan 2017 09:26:00 -0000 Message-ID: Subject: Re: C++11 thread_local implementation issue on Cygwin/AMD64 To: cygwin@cygwin.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2017-01/txt/msg00307.txt.bz2 On 9 February 2016 at 15:23, V=C3=A1clav Haisman wrote: > On 19 May 2015 at 10:52, V=C3=A1clav Haisman wrote: >> On 19 January 2015 at 15:42, V=C3=A1clav 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 =3D new S; >>> return ptd; >>> } >>> } // namespace N >>> ~~~~ >>> >>> File def.cxx: >>> >>> ~~~~ >>> #include "def.hxx" >>> >>> namespace N >>> { >>> // definition of ptd >>> thread_local S * ptd =3D 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=3Dgnu++11 >>> -fvisibility=3Dhidden -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=3D64697. > > Annual ping. :) Annual ping for 2017. :) --=20 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