On Tuesday, 26 May 2015 at 16:25:52 UTC, bitwise wrote:
> 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.

That only works when the host executable is linked against druntime, but falls when you load runtime dynamically, e.g. a D plugin for a C host.

On Wednesday, 27 May 2015 at 06:45:49 UTC, Jacob Carlborg wrote:
> 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.

On Linux you call it with an dso index and an offset. The DSO index is assigned by the runtime linker (there is a special relocation for that). Something similar could be done manually if not natively supported on OSX.

On Tuesday, 26 May 2015 at 16:25:52 UTC, bitwise wrote:
>> Isn't it better to avoid private undocumented functions?
> Not only better, but mandatory, otherwise Apple will reject the app from the app store.

Calling back into an unloaded image without proving a mean to deregister the callback is a bug, so you might fix it.

Looking at the code [1] again there is also an interesting sImagesToNotifyAboutOtherImages.

[1]: http://opensource.apple.com/source/dyld/dyld-95.3/src/dyld.cpp

On 2015-05-27 15:38, Martin Nowak wrote:

> On Linux you call it with an dso index and an offset. The DSO index is
> assigned by the runtime linker (there is a special relocation for that).
> Something similar could be done manually if not natively supported on OSX.

It is natively support.

-- 
/Jacob Carlborg

On Wed, 27 May 2015 02:45:57 -0400, Jacob Carlborg <doob@me.com> wrote:
>
> 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?

Good point.

I've come up another solution and posted it here:
http://dpaste.com/0DXBSNQ

Basically, I've gone back to the idea of using the dylib ctor/dtors. I don't think we really even need the image-added callback, at least not for dylibs.

I callback could still be used when the main application is written in D, but we could also replace it with my solution in the dpaste(the getThisImageInfo function).

As far as TLS goes, I haven't looking into the details of actually initializing the images yet. Once we have a solution for when and how to initialize the dylibs, I'll move on to the specifics... pun intended ;)

I think the solution above may be a winner though.

    Bit

On 2015-05-27 23:24, bitwise wrote:

> Good point.
>
> I've come up another solution and posted it here:
> http://dpaste.com/0DXBSNQ

BTW, I'm not sure what's the best solution but you can calculate the slide without iterating all images. Look at the first statements in "tlv_allocate_and_initialize_for_key" in [1]. Specifically where it sets the "slide" variable.

> Basically, I've gone back to the idea of using the dylib ctor/dtors. I
> don't think we really even need the image-added callback, at least not
> for dylibs.
>
> I callback could still be used when the main application is written in
> D, but we could also replace it with my solution in the dpaste(the
> getThisImageInfo function).

I think it would be simpler to only have one way to do this.

> As far as TLS goes, I haven't looking into the details of actually
> initializing the images yet. Once we have a solution for when and how to
> initialize the dylibs, I'll move on to the specifics... pun intended ;)

Fair enough.

> I think the solution above may be a winner though.

I agree, but I think ctor/dtors can be used for the executable as well.

[1] http://opensource.apple.com/source/dyld/dyld-353.2.1/src/threadLocalVariables.c

-- 
/Jacob Carlborg

On Wednesday, 27 May 2015 at 21:24:25 UTC, bitwise wrote:
> Basically, I've gone back to the idea of using the dylib ctor/dtors. I don't think we really even need the image-added callback, at least not for dylibs.

Looks good. The compiler could add a simple ctor/dtor to any D object.

On 2015-05-27 23:24, bitwise wrote:

> Good point.
>
> I've come up another solution and posted it here:
> http://dpaste.com/0DXBSNQ

Will "dladdr" return different values (mach_header) for different dynamic libraries? Won't there only be one "init" function, as you said earlier. Or does it work somehow anyway?

-- 
/Jacob Carlborg

On Friday, 29 May 2015 at 12:46:43 UTC, Jacob Carlborg wrote:
> On 2015-05-27 23:24, bitwise wrote:
>
>> Good point.
>>
>> I've come up another solution and posted it here:
>> http://dpaste.com/0DXBSNQ
>
> Will "dladdr" return different values (mach_header) for different dynamic libraries? Won't there only be one "init" function, as you said earlier. Or does it work somehow anyway?

I'm going to test it out this weekend, but if I do get the wrong address, I think I can add a symbol with "__attribute__ ((visibility ("hidden")))" and use dladdr on that instead. I don't think hidden symbols should collide.

On 2015-05-29 18:45, bitwise wrote:

> I'm going to test it out this weekend, but if I do get the wrong
> address, I think I can add a symbol with "__attribute__ ((visibility
> ("hidden")))" and use dladdr on that instead. I don't think hidden
> symbols should collide.

Doesn't "dlopen" open the current image if "null" is passed? And that void* which is returned is actually a "mach_header*", if I recall correctly.

-- 
/Jacob Carlborg