DIP45: fixing the dllimport/dllexport issue

[Benjamin Thaut]

Am 01.09.2013 19:58, schrieb 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.

Is this a issue? There just would be some unused exports in the dll, 
wouldn't it? If this really is a problem we could add a compiler switch 
to stop implict exporting of 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.
>

I would say whatever works best for the plattform at hand. No need to 
force one way or the other.

>>
>>>
>>> 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.

Can't we initialize these right before running the shared module 
constructors? To make the implementation less work we could also make 
this a error for now and maybe implement it later. What would you prefer?

>
> Rainer