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 <[email protected]> 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<[email protected]> 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 >> [email protected] >> http://lists.puremagic.com/mailman/listinfo/dmd-internals >> > > _______________________________________________ > dmd-internals mailing list > [email protected] > http://lists.puremagic.com/mailman/listinfo/dmd-internals _______________________________________________ dmd-internals mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/dmd-internals
