Dynamic loading, D all the way (dmd 64bit 2.060/Ubuntu 64bit 12.04/x86_64)

[Jacob Carlborg]

On 2012-08-20 17:16, Carl Sturtivant wrote:
>
>>
>> I'm not sure I'm following what you exactly have done here but in
>> general this is what needs to be done to make dynamic libraries
>> properly work in D :
>>
>> * Initialize module infos (module constructors and similar)
>> * Add TLS variables
>> * Add exception handling tables
>> * Add GC roots
>>
>> The above four things need to be extracted from the loaded dynamic
>> library and it gets loaded and preferably remove them as well when the
>> dynamic library gets unloaded. Currently this is only extracted from
>> the running executable. This is platform dependent but usually it's
>> extracted using bracketed sections via extern C variables.
>
> OK, good to know. Any further hints about these, or where I can look?

 From druntime:

* rt.minfo - module infos. The "_moduleinfo_array" variable contains the 
module infos.

* rt.deh2 - exception handling. On Mac OS X the "_deh_eh_array" contains 
the exception handling tables. On the other Posix systems the sections 
bracketed by "_deh_beg" and "_deh_end" contains the tables.

* rt.thread - threading, TLS. On Mac OS X the TLS variables are stored 
in "_tls_data_array". On the other Posix systems they're are again 
stored in bracketed sections: "_tlsstart" and "_tlsend".

* rt.memory - GC roots. I think this module contains code related to 
adding GC roots. rt.memory_osx for Mac OS X.

You can also take a look at work by Martin Nowak:

https://github.com/dawgfoto/druntime/commits/SharedRuntime

> What I've done is use the C dynamic loading library (header dlfcn.h) to
> manually load a shared object written in D, dload.d, from a D program
> (main.d), which then successfully calls functions in dload.d that are
> not defined extern(C).
>
> I am attempting a do-it-yourself dynamic loading in D, where I
> explicitly do all the administration manually to make it work, rather
> than rely upon D to do it automatically. Hence my use of the C dynamic
> loading library, which knows nothing of additional work D must do.

The functions from dlfcn.h is what D would use as well. Possibly wrapped 
in some D function that does some additional work.

-- 
/Jacob Carlborg