[dmd-internals] __tls_callbacks_a

[Rainer Schuetze]

You have to redefine both symbols _tls_index and _tls_used.

On 20.01.2012 08:41, Alex wrote:
> This doesn't seem to work:
>
> __gshared extern(C) int _tls_used = 0;
>
> int main()
> {
>      return _tls_used;
> }
> E:\>dmd test.d
> OPTLINK (R) for Win32  Release 8.00.12
> Copyright (C) Digital Mars 1989-2010  All rights reserved.
> http://www.digitalmars.com/ctg/optlink.html
> c:\d\dmd2\windows\bin\..\lib\snn.lib(tlsdata)  Offset FD6A3H Record Type 0091
> Error 1: Previous Definition Different : __tls_used
> --- errorlevel 1
>
> Maybe I'm not following you though.
>
> Regards,
> Alex
>
> On Thu, Jan 19, 2012 at 10:56 PM, Rainer Schuetze<r.sagitario at gmx.de>  wrote:
>> That's no problem if the symbol is from a library and you don't reference
>> other symbols in the same module. This compiles and links:
>>
>> extern(C) int _tls_index;
>> extern(C) void* _tls_used[6];
>>
>> void main()
>> {
>> }
>>
>> If you check the map file, you will see that tlsdata is no longer used.
>>
>>
>> On 19.01.2012 22:35, Alex wrote:
>>> Problem is that the symbol is a strong reference, so redefining it
>>> will just give a duplicate symbol error. :/
>>>
>>> Regards,
>>> Alex
>>>
>>> On Thu, Jan 19, 2012 at 10:28 PM, Rainer Schuetze<r.sagitario at gmx.de>
>>>   wrote:
>>>> Can't you declare the symbols (_tls_index and _tls_used) in the tlsdata
>>>> module elsewhere (not in a library), so the module will not be taken from
>>>> the library? Then you can set your own list of callbacks.
>>>>
>>>>
>>>> On 19.01.2012 22:11, Alex wrote:
>>>>> Hi,
>>>>>
>>>>>> Maybe you can patch the corresponding entry off the _tls_used data
>>>>>> struct
>>>>>> very early, so the TLS callback are called when necessary.
>>>>> Unfortunately, it seems the PE loader loads it immediately, so
>>>>> patching at runtime is virtually impossible. :(
>>>>>
>>>>> (We did think of doing a horrible hack (detouring
>>>>> LdrShutdownThread()), but this is insane for many reasons...)
>>>>>
>>>>> My guess is that the symbol is just defined always for convenience, as
>>>>> it's necessary for C/C++ code using TLS. However, this clearly imposes
>>>>> problems on D users, as we have no way of utilizing the symbol
>>>>> correctly.
>>>>>
>>>>> The last resort is to simply patch snn.lib but this obviously
>>>>> complicates the build process a LOT. We'd really like to avoid this...
>>>>>
>>>>> Regards,
>>>>> Alex
>>>>>
>>>>> On Thu, Jan 19, 2012 at 9:38 PM, Rainer Schuetze<r.sagitario at gmx.de>
>>>>>   wrote:
>>>>>> _tls_callbacks_a is defined to a single zero entry in the C runtime
>>>>>> library,
>>>>>> see the module tlsdata.obj from snn.lib.
>>>>>>
>>>>>> I guess you know this, but here's a very in depth article about TLS
>>>>>> under
>>>>>> windows: http://www.nynaeve.net/?p=183
>>>>>>
>>>>>> Maybe you can patch the corresponding entry off the _tls_used data
>>>>>> struct
>>>>>> very early, so the TLS callback are called when necessary.
>>>>>>
>>>>>>
>>>>>> On 19.01.2012 11:40, Alex wrote:
>>>>>>> Anyone have a clue? As said, this is quite essential for implementing
>>>>>>> a TLS-supporting VM in D.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Alex
>>>>>>>
>>>>>>> On Tue, Jan 17, 2012 at 8:59 AM, Alex<xtzgzorex at gmail.com>        wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> It seems that either DMD or Optlink is emitting this symbol, most
>>>>>>>> likely because it was expected that users would like to define TLS
>>>>>>>> callbacks. However, in D we have nothing like _CRTALLOC() or
>>>>>>>> __declspec(allocate()), so we cannot specify that we want a callback
>>>>>>>> registered there. This callback is rather essential for a virtual
>>>>>>>> machine that me and a few others are working on, so is there some
>>>>>>>> kind
>>>>>>>> of workaround we could use? Or perhaps we're just missing the way
>>>>>>>> this
>>>>>>>> is supposed to used in the first place?
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Alex
>>>>>>> _______________________________________________
>>>>>>>
>>>>>>> dmd-internals mailing list
>>>>>>> dmd-internals at puremagic.com
>>>>>>> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>>>>>>>
>>>>>> _______________________________________________
>>>>>> dmd-internals mailing list
>>>>>> dmd-internals at puremagic.com
>>>>>> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>>>>> _______________________________________________
>>>>> dmd-internals mailing list
>>>>> dmd-internals at puremagic.com
>>>>> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>>>>>
>>>> _______________________________________________
>>>> dmd-internals mailing list
>>>> dmd-internals at puremagic.com
>>>> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>>> _______________________________________________
>>> dmd-internals mailing list
>>> dmd-internals at puremagic.com
>>> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>>>
>> _______________________________________________
>> dmd-internals mailing list
>> dmd-internals at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/dmd-internals
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals
>