[phobos] Showstopper bug: Hello world fails on OSX!

[Michel Fortin]

Le 2010-11-10 à 4:55, Jacob Carlborg a écrit :

> I've been thinking about this and I'm trying to think of everything to get this right the first time so I have a couple of questions:
> 
> * I though it might be a good idea to add support for running module constructors for dynamically loaded libraries (i.e. libraries loaded with dlopen). Then I was think I need to add the new module infos to the array of existing ones and when/if the library is unloaded remove the module infos added by the library. Now for the question: is an array still a good data structure for this or should we use an associative array or something else?

The Objective-C runtime uses a linked list. I think the expectation is that you won't have thousands of libraries open and that you won't unload them often. But going with an AA doesn't look like a bad idea to me.


> * If we change to an associative array could the image received in the callback function registered by _dyld_register_func_for_add_image be used as the key in the associative array?

That's what the Objective-C runtime does (it stores them in a linked list and compare linearly all the entries in the unload callback).


> * This is a question about the _dyld_register_func_for_add_image function. Can I assume that all images sent to the registered callback functions are of the same architecture that I'm currently compiling? For example, I'm running a universal binary and it's running the 32bit part of the binary. Then I'm loading a universal dynamic library, it will only load the 32bit part since that's the part I'm running?

I think you can. I see nowhere in the Objective-C runtime where this is checked, and it'd just be quite strange if the dynamic linker did that.


> * What to name the function, where to put it and when to call it?

It's called 'map_image' and 'unmap_image' in the Objective-C runtime. But I don't know how they should be named in Druntime.


-- 
Michel Fortin
michel.fortin at michelf.com
http://michelf.com/