DIP45: fixing the dllimport/dllexport issue

[Rainer Schuetze]

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