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

[Walter Bright]

I'll have to leave these to Sean, I am not very competent on how things 
work on OSX.

One way to deal with the moduleinfos is to have it be an array of array 
of moduleinfos, then adding/removing as .so's are added/removed becomes 
a cinch. Using associative arrays may produce problems with 
initialization - if a future aa implementation requires module construction.

Jacob Carlborg wrote:
> 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?
>
> * 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?
>
> * 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?
>
> * What to name the function, where to put it and when to call it?
>
> On 9 nov 2010, at 21:23, Walter Bright wrote:
>
>   
>> Sean Kelly wrote:
>>     
>>> On Nov 9, 2010, at 11:55 AM, Walter Bright wrote:
>>>  
>>>       
>>>> Jacob Carlborg wrote:
>>>>    
>>>>         
>>>>> It should work using getsectdatafromheader, that's what I changed when I added support for dynamic libraries to Tango. Have a look at the Tango code: http://dsource.org/projects/tango/browser/trunk/tango/core/rt/compiler/dmd/object_.d#L1270 and http://dsource.org/projects/tango/browser/trunk/tango/core/rt/compiler/dmd/darwin/Image.d#L103 . The file in the last link is completely made by me so you won't have to be afraid for looking at it. Or if you don't want to look at Tango source files at all you can look at this druntime change: http://www.dsource.org/projects/druntime/changeset/372 , to be more specific: http://www.dsource.org/projects/druntime/browser/trunk/src/rt/image.d?rev=372#L105
>>>>>      
>>>>>           
>>>> Thanks, Jacob! If you want to submit a patch to druntime that, for OSX, eliminates the dependence on the begin and end sections, that would be awesome.
>>>>    
>>>>         
>>> The simplest (appropriate) fix for the way things work today would probably be to add a new compiler runtime routine like "extern (C) void[] rt_tlsseg()".  Then all of the compiler-specific logic for TLS segment management can be moved into src/rt/memory.d (and possibly memory_osx.c).  I've been meaning to do something about this code being in core.thread anyway, since it really is compiler-specific.
>>>
>>>  
>>>       
>> The segment begin/end issue is exactly the same for exception handling and moduleinfo. A solution for one should do all three.
>> _______________________________________________
>> phobos mailing list
>> phobos at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/phobos
>>     
>
>