[D-runtime] Runtime issue on Mac OS X

[Jacob Carlborg]

On 20 jun 2012, at 19:28, Sean Kelly wrote:

> A lot of work needs to be done to support dynamic libraries properly.  Thread lists need to be dynamically merged and unmerged, static segment info, ModuleInfo, etc.  We already have Runtime.load/unloadLibrary, so if we assume that D programmers will always call these instead of dlopen/dlclose directly then we just need to make sure the routines handle both C and D dynamic libraries appropriately.  Also, it should be possible to use the same D dynamic library with both C and D apps, which I guess means that Druntime would have to live in its own dynamic library as well.


Yeah, I know. I know in theory what's need to be done (and I'm probably missing somethings here as well). But it's these particle things that cause problems, like _dyld_register_func_for_add_image probably can't be used.

Are you suggesting _dyld_register_func_for_add_image should not be used and to all initialization in Runtime.load?

_dyld_register_func_for_add_image is used to get the mach_header of a loaded image (dynamic library or executable) which is needed to get module info, TSL data and so on. How should that be obtained otherwise:

* Iterating all loaded images - Sure, it works, I've done that, but it not as pretty

* Bracketing sections with empty sections, i.e. _tls_beg, _tls_end - I would rather not go back to this solution. It was recently removed in favor of getsectbynamefromheader (which requires a  mach_header) because it's much more reliable. We won't have problems with newer version of the linker

* Using "dladdr" somehow to get the mach_header

* Other suggestions I'm not aware of / have missed

If we can use "dyld_register_image_state_change_handler" that would be nice. But as I've said, it's a private function. Also I don't think it's possible to unload a dynamic library which uses this function. Although the Objective-C runtime uses it so I don't know if it's a problem or not.

-- 
/Jacob Carlborg