On 01.09.2013 18:43, Benjamin Thaut wrote:
Am 01.09.2013 17:26, schrieb Rainer Schuetze:
On 01.09.2013 11:49, Benjamin Thaut wrote:
I updated the DIP with all discussed content. Feedback is welcome.
http://wiki.dlang.org/DIP45
Kind Regards
Benjamin Thaut
LGTM.
Lets get this merged? ^^ First someone has to implement it ;-)
What about the current use case of just exporting some functions for
being loaded by a C application? It should still work using a def-file
(which you have to use anyway most of the time due to
http://d.puremagic.com/issues/show_bug.cgi?id=3956)
Well you can still use a .def file of course. Also no one stops you just
annotating simple extern(C) functions with the export attribute. I don't
see any problem there.
It would export the ModuleInfo and related symbols.
Maybe already deep into implementation but how are we going to deal with
the initialization of data?
module sharedlib;
__gshared int var;
module exe;
import sharedlib;
__gshared int* pvar = &var;
(This kind of relocation also has to be done for stuff like
TypeInfo_Class). It needs initialization code to fill pvar with the
correct pointer.
Yes, you are absolutely correct. I don't know enough about the internals
of a compiler (dmd in perticular) though to answer this question. Can't
we use the same mechanism C++ uses to run all its initializers?
Yes, it would be an option to generate init functions to be run with the
C initializers. But that might introduce a dependency on initialization
order. We can write relocation info into another segment and do the
relocations before runtime init.
Do we support the same for pointers in TLS?
int* tlsvar = &var;
This might need initialization per thread, or patching the original TLS
segment.
The DIP has a seperate section on TLS variables. Did you miss to read that?
No. I meant thread global variables that are preinitialized. The
appropriate relocation doesn't exist, the __acccess_tls_var function has
to be called in a thread local init function.
Rainer
