From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11701 invoked by alias); 5 Sep 2012 13:40:58 -0000 Received: (qmail 11608 invoked by uid 22791); 5 Sep 2012 13:40:55 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,SPF_NEUTRAL,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from bureau60.ns.utoronto.ca (HELO bureau60.ns.utoronto.ca) (128.100.132.147) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 05 Sep 2012 13:40:32 +0000 Received: from [192.168.0.100] (69-165-139-247.dsl.teksavvy.com [69.165.139.247]) (authenticated bits=0) by bureau60.ns.utoronto.ca (8.13.8/8.13.8) with ESMTP id q85DeFr2028541 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 5 Sep 2012 09:40:24 -0400 Message-ID: <50475646.7050603@cs.utoronto.ca> Date: Wed, 05 Sep 2012 14:04:00 -0000 From: Ryan Johnson User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/20120824 Thunderbird/15.0 MIME-Version: 1.0 To: cygwin@cygwin.com Subject: Re: limitations of TLS using GCC's __thread keyword and Cygwin References: <504612A3.6070605@cs.utoronto.ca> <50466981.70005@gmail.com> <20120904215129.GA30731@ednor.casa.cgf.cx> In-Reply-To: Content-Type: multipart/mixed; boundary="------------070202060009040301080004" X-IsSubscribed: yes 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 X-SW-Source: 2012-09/txt/msg00068.txt.bz2 --------------070202060009040301080004 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Content-length: 3330 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). Ryan --------------070202060009040301080004 Content-Type: text/plain; charset=windows-1252; name="tls.cpp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="tls.cpp" Content-length: 1428 I2luY2x1ZGUgPHB0aHJlYWQuaD4KI2luY2x1ZGUgPGNzdGRpbz4KI2luY2x1 ZGUgPHVuaXN0ZC5oPgojaW5jbHVkZSA8ZGxmY24uaD4KCl9fdGhyZWFkIGlu dCBteV9pbnQ7Cgpib29sIGdvID0gZmFsc2U7CmV4dGVybiAiQyIgdm9pZCog cnVuKHZvaWQqIG9iaikgewogICAgaW50ICooKmdldF9leHRfdGxzKSgpID0g KGludCooKikoKSkgZGxzeW0ob2JqLCAiZ2V0X2V4dF9pbnQiKTsKICAgIGlu dCAqKCpnZXRfbXlfdGxzKSgpID0gKGludCooKikoKSkgZGxzeW0ob2JqLCAi Z2V0X215X2ludCIpOwogICAgaW50ICpleHRfaW50ID0gKGludCopIGRsc3lt KG9iaiwgImV4dF9pbnQiKTsKICAgIGludCAqbXlfdGxzID0gZ2V0X215X3Rs cygpOwogICAgaW50ICpleHRfdGxzID0gZ2V0X2V4dF90bHMoKTsKICAgIHdo aWxlKG5vdCBnbykKICAgICAgICB1c2xlZXAoMTAwKjEwMDApOwoKICAgIHBy aW50ZigidGlkPSV4LCAmbXlfaW50PSVwLCAmbXlfdGxzPSVwLCAmZXh0X2lu dD0lcCwgJmV4dF90bHM9JXBcbiIsCiAgICAgICAgICAgKGludClwdGhyZWFk X3NlbGYoKSwgJm15X2ludCwgbXlfdGxzLCBleHRfaW50LCBleHRfdGxzKTsK ICAgIHJldHVybiAwOwp9CmludCBtYWluKCkgewogICAgdm9pZCogb2JqID0g ZGxvcGVuKCJleHQtdGxzIiwgMCk7CiAgICBpZiAobm90IG9iaikKICAgICAg ICBmcHJpbnRmKHN0ZGVyciwgIlVuYWJsZSB0byBvcGVuIGRsbDogJXNcbiIs IGRsZXJyb3IoKSk7CiAgICAKICAgIHB0aHJlYWRfdCB0aWRzWzEwXTsKICAg IGZvcih1bnNpZ25lZCBpPTA7IGkgPCBzaXplb2YodGlkcykvc2l6ZW9mKCp0 aWRzKTsgaSsrKQogICAgICAgIHB0aHJlYWRfY3JlYXRlKCZ0aWRzW2ldLCAw LCAmcnVuLCBvYmopOwoKICAgIGZwcmludGYoc3RkZXJyLCAicGlkOiAlZFxu IiwgZ2V0cGlkKCkpOwogICAgc2xlZXAoMSk7CiAgICBnbyA9IHRydWU7CiAg ICBydW4ob2JqKTsKCiAgICBmb3IodW5zaWduZWQgaT0wOyBpIDwgc2l6ZW9m KHRpZHMpL3NpemVvZigqdGlkcyk7IGkrKykKICAgICAgICBwdGhyZWFkX2pv aW4odGlkc1tpXSwgMCk7Cn0K --------------070202060009040301080004 Content-Type: text/plain; charset=windows-1252; name="ext-tls.cpp" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ext-tls.cpp" Content-length: 232 ZXh0ZXJuICJDIiB7CiAgICBfX3RocmVhZCBpbnQgZXh0X2ludDsKICAgIAog ICAgZXh0ZXJuIF9fdGhyZWFkIGludCBteV9pbnQ7CiAgICAKICAgIGludCog Z2V0X2V4dF9pbnQoKSB7IHJldHVybiAmZXh0X2ludDsgfQogICAgaW50KiBn ZXRfbXlfaW50KCkgeyByZXR1cm4gJm15X2ludDsgfQp9Cg== --------------070202060009040301080004 Content-Type: text/plain; charset=us-ascii Content-length: 218 -- 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 --------------070202060009040301080004--