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 > [email protected] > http://lists.puremagic.com/mailman/listinfo/phobos -- /Jacob Carlborg _______________________________________________ phobos mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/phobos
