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.

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)

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.

Do we support the same for pointers in TLS?

int* tlsvar = &var;

This might need initialization per thread, or patching the original TLS segment.

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.

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

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

Kind Regards
Benjamin Thaut

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

On Sunday, 1 September 2013 at 16:43:14 UTC, Benjamin Thaut wrote:
> The DIP has a seperate section on TLS variables. Did you miss to read that?

Can't we just use the normal (g)libc facilities for handling TLS in shared objects on Linux? The TLS data from the "DLL" is assigned to another tls module, and everything is fine, or am I missing something?

David

On 1 September 2013 19:16, David Nadlinger <code@klickverbot.at> wrote:
> On Sunday, 1 September 2013 at 16:43:14 UTC, Benjamin Thaut wrote:
>>
>> The DIP has a seperate section on TLS variables. Did you miss to read that?
>
>
> Can't we just use the normal (g)libc facilities for handling TLS in shared objects on Linux? The TLS data from the "DLL" is assigned to another tls module, and everything is fine, or am I missing something?
>
> David

Yes, no need to invent a new cog to go on top of what the base runtime already offers.

-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

Am 01.09.2013 21:19, schrieb Iain Buclaw:
> On 1 September 2013 19:16, David Nadlinger <code@klickverbot.at> wrote:
>> On Sunday, 1 September 2013 at 16:43:14 UTC, Benjamin Thaut wrote:
>>>
>>> The DIP has a seperate section on TLS variables. Did you miss to read
>>> that?
>>
>>
>> Can't we just use the normal (g)libc facilities for handling TLS in shared
>> objects on Linux? The TLS data from the "DLL" is assigned to another tls
>> module, and everything is fine, or am I missing something?
>>
>> David
>
> Yes, no need to invent a new cog to go on top of what the base runtime
> already offers.
>

I didn't know linux has a facility for accessing TLS data across shared library boundaries. I will put the implementation suggestion into the windows specific section then.

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

Am 01.09.2013 21:19, schrieb Iain Buclaw:
> On 1 September 2013 19:16, David Nadlinger <code@klickverbot.at> wrote:
>> On Sunday, 1 September 2013 at 16:43:14 UTC, Benjamin Thaut wrote:
>>>
>>> The DIP has a seperate section on TLS variables. Did you miss to read
>>> that?
>>
>>
>> Can't we just use the normal (g)libc facilities for handling TLS in shared
>> objects on Linux? The TLS data from the "DLL" is assigned to another tls
>> module, and everything is fine, or am I missing something?
>>
>> David
>
> Yes, no need to invent a new cog to go on top of what the base runtime
> already offers.
>

Basically I thought whatever is inside the Description would go into the spec. Everything inside the implementation details is just a suggestion for implementing proper dllexport / dllimport on windows plattforms. We shouldn't hard wire these implementation suggestions into the spec.

On Friday, 30 August 2013 at 10:50:40 UTC, Rainer Schuetze wrote:
> Just remembered that we don't have that in Windows

Why? What's the difference between code and data symbols? I thought, they're just addresses.

On 03.09.2013 08:17, Kagamin wrote:
> On Friday, 30 August 2013 at 10:50:40 UTC, Rainer Schuetze wrote:
>> Just remembered that we don't have that in Windows
>
> Why? What's the difference between code and data symbols? I thought,
> they're just addresses.

Inside an executable/DLL image, all relocations are relative to the image itself, only the import table has references to other DLLs.

To initialize data with a pointer into another DLL, you cannot do that with a direct relocation, you have to run some code to copy the value from the import table into the data.

Accessing data or functions in another DLL from code already has this extra code compiled in.