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<[email protected]> 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<[email protected]>
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<[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
_______________________________________________
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
_______________________________________________
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
