[dmd-internals] __tls_callbacks_a

[Alex]

Redefining both links fine, but the one from snn.lib seems to be
picked over my definition. Code:

__gshared extern(C) int _tls_used = 0;
__gshared extern(C) int _tls_index = 0;

int main()
{
    return _tls_used + _tls_index;
}

Regards,
Alex

On Fri, Jan 20, 2012 at 9:33 AM, Rainer Schuetze <r.sagitario at gmx.de> wrote:
> 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
>>
>
> _______________________________________________
> dmd-internals mailing list
> dmd-internals at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/dmd-internals