[dmd-internals] __tls_callbacks_a

[Alex]

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