[dmd-internals] __tls_callbacks_a

Rainer Schuetze r.sagitario at gmx.de
Thu Jan 19 13:28:27 PST 2012


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
>



More information about the dmd-internals mailing list