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