On 2015-05-26 18:25, bitwise wrote:
I think Martin is right. We don't need ctors/dtors or any compiler
fanciness. All we need is the two callbacks, which can be registered
when druntime is initialized.
_dyld_register_func_for_add_image
_dyld_register_func_for_remove_image
At this point, we would only be registering the callbacks once in the
main image, and not from the shared library. Since all global functions
and symbols are shared between images anyways, receiving the callback in
the main image would be fine. So in this case, unregistering the
callbacks is no longer needed.
What about using a D dynamic library in a C application? The C
application would initialize the runtime which would register the
callback. Then it would be undefined to unload druntime?
How would loading shared libraries change this? Couldn't TLS, however
it's implemented now, be applied to shared libraries as well?
I'm not sure. The ___tls_get_addr function [1] is used when accessing a
TLS variable on OS X. In all native implementations, both on OS X and
Linux, the parameter is not just a void* but struct containing the image
header as well.
Looking at SectionGroup [2] and how its data is initialized [3] you can
see that there's only one set of TLS data (__tls_data and __tlscoal_nt)
in SectionGroup. It would be straight forward to change that to an array
but then you would not know which index to access in getTLSBlockAlloc
[4] which is used by ___tls_get_addr.
[1]
https://github.com/D-Programming-Language/druntime/blob/master/src/rt/sections_osx.d#L115
[2]
https://github.com/D-Programming-Language/druntime/blob/master/src/rt/sections_osx.d#L26
[3]
https://github.com/D-Programming-Language/druntime/blob/master/src/rt/sections_osx.d#L227-L239
[4]
https://github.com/D-Programming-Language/druntime/blob/master/src/rt/sections_osx.d#L172
--
/Jacob Carlborg
