Mail Archives: cygwin/2012/09/05/09:41:18
--------------070202060009040301080004
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
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"
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"
ZXh0ZXJuICJDIiB7CiAgICBfX3RocmVhZCBpbnQgZXh0X2ludDsKICAgIAog
ICAgZXh0ZXJuIF9fdGhyZWFkIGludCBteV9pbnQ7CiAgICAKICAgIGludCog
Z2V0X2V4dF9pbnQoKSB7IHJldHVybiAmZXh0X2ludDsgfQogICAgaW50KiBn
ZXRfbXlfaW50KCkgeyByZXR1cm4gJm15X2ludDsgfQp9Cg==
--------------070202060009040301080004
Content-Type: text/plain; charset=us-ascii
--
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--
- Raw text -