X-Recipient:	archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status:	No, hits=-5.3 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE
X-Spam-Check-By:	sourceware.org
MIME-Version:	1.0
In-Reply-To:	<50475646.7050603@cs.utoronto.ca>
References:	<CAKw7uVgy4qgeqVMk1dRPb=Lr-so5NP3e6XjER=ZGqd+B+MT3ZQ AT mail DOT gmail DOT com> <504612A3 DOT 6070605 AT cs DOT utoronto DOT ca> <50466981 DOT 70005 AT gmail DOT com> <20120904215129 DOT GA30731 AT ednor DOT casa DOT cgf DOT cx> <CAKw7uVgXkEktUOE_c6uhZXkZOng0DB6ja2mMHwPik+3iJemo3w AT mail DOT gmail DOT com> <50475646 DOT 7050603 AT cs DOT utoronto DOT ca>
Date:	Wed, 5 Sep 2012 16:49:24 +0200
Message-ID:	<CAKw7uVhdbQCb6kGs0ZVLtRNvJCimpkx7+24_72SC-c7_Q+iXnQ@mail.gmail.com>
Subject:	Re: limitations of TLS using GCC's __thread keyword and Cygwin
From:	=?UTF-8?Q?V=C3=A1clav_Zeman?= <vhaisman AT gmail DOT com>
To:	cygwin AT cygwin DOT com
X-IsSubscribed:	yes
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Unsubscribe:	<mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
X-MIME-Autoconverted:	from quoted-printable to 8bit by delorie.com id q85Eo3UF013224

On 5 September 2012 15:40, Ryan Johnson wrote:
> On 05/09/2012 4:05 AM, Václav Zeman wrote:
>>
>> On 4 September 2012 23:51, Christopher Faylor wrote:
>>>
>>> On Tue, Sep 04, 2012 at 10:50:09PM +0200, V??clav Zeman wrote:
>>>>
>>>> On 09/04/2012 04:39 PM, Ryan Johnson wrote:
>>>>>
>>>>> On 04/09/2012 8:58 AM, V??clav Zeman wrote:
>>>>>>
>>>>>> Hi.
>>>>>>
>>>>>> I am am porting a library that can use the __thread keyword in its
>>>>>> internals to provide thread local storage. Now, with MSVC there is a
>>>>>> limitation on pre-Vista Windows (see [1]) that DLLs using
>>>>>> __declspec(thread) (MSVC equivalent of GCC's __thread) cannot be
>>>>>> loaded using LoadLibrary() because pre-Vista Windows allocate the TLS
>>>>>> declared that way only on process startup. Vista and later Windows do
>>>>>> not seem to have the limitation. Since Cygwin officially still
>>>>>> supports at least Windows XP, I want to provide a library that works
>>>>>> there as well.
>>>>>>
>>>>>> Does Cygwin's GCC and its TLS emulation work around this problem? IOW,
>>>>>> are Cygwin DLLs using TLS declared using __thread keyword safe to be
>>>>>> loaded using LoadLibrary()/dlopen() or are they not safe to be loaded
>>>>>> that way?
>>>>>>
>>>>>> [1] http://msdn.microsoft.com/en-us/library/2s9wt68x.aspx
>>>>>>
>>>>> I suspect it's not a problem, but if I were you I'd write a simple
>>>>> test program to see. Unfortunately, TLS in general seems broken on my
>>>>> machine when I tried it, but that might be due to my home-brew gcc
>>>>> being configured wrong or something.
>>>>
>>>> I would have done that already but I do not have any Windows XP machine
>>>> to try this on.
>>>
>>> I don't believe that __thread is implemented on Cygwin.
>>
>> Adjust your beliefs. :) It is implemented and it works correct as far
>> as I can tell. It implements TLS using calls to __emutls* routines.
>> What I am unclear about is whether the implemention works around the
>> limitation mentioned in the MSDN link or not.
>
> GCC collects all TLS "slots" into a giant struct and then associates one
> copy of that struct with each thread. On targets without ABI support for
> TLS, the association is made using a single posix thread-local key. See gcc
> sources, libgcc/emutls.c for gory details.
>
> Because the giant-TLS-struct is associated with a single Windows TLS slot,
> there should be no particular limitations on its use compared with linux.
>
> Note, however, that you can't directly access TLS of a dlopen'd object:
> dlsym looks for a "normal" variable, failing because it doesn't exist.
> However, code inside the dlopened object can access its TLS correctly (so
> you could write a wrapper to return the TLS pointer), and dlopened objects
> can also correctly access TLS declared in the main object if you link them
> properly [1].
>
> [1] http://cygwin.com/faq.html#faq.programming.unix-gui
>
> STC attached, compile with:
>
> g++ -Wl,--export-all-symbols,--out-implib,liba.exe.a tls.cpp && g++ -shared
> ext-tls.cpp liba.exe.a -oext-tls.dll && ./a
>
> Caveat: I'm not completely sure how the dlopen'd file creates its TLS block,
> because there's no way it can share the same one as the main app. If it
> needs to create a new Windows TLS slot at load time, you may hit problems
> under Windows XP; I got some strange behavior running the STC under XP
> compatability mode on my Win7 machine (though oddly, it was the main object
> that broke; the dlopen'd object worked correctly).
Thank you for this testing. I guess that the safest course of action
for me is to rely only on own instance of pthread_key_t then.

-- 
VZ

--
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

- Raw text -