shared libs for OSX

[Jacob Carlborg via Digitalmars-d]

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