On 09/01/2013 05:26 PM, Rainer Schuetze wrote:
>
> 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.
>
Based on your saying that there are no absolute data relocations for this on windows we'd have to perform runtime initialization.
At runtime it would simply copy _imp_var into pvar, right?

> Do we support the same for pointers in TLS?
>
> int* tlsvar = &var;
>
> This might need initialization per thread, or patching the original TLS
> segment.
No you can't take the address of a TLS var at compile time.

On 09/01/2013 09:33 PM, Benjamin Thaut wrote:
>
> 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.

Yes, it has a bunch of special relocations and runtime linker support for this.
It would be nice if someone could figure out and summarize all the TLS index and TIB business on Windows.

http://msdn.microsoft.com/en-us/library/windows/desktop/ms686997(v=vs.85).aspx
http://en.wikipedia.org/wiki/Thread-local_storage#Windows_implementation
http://en.wikipedia.org/wiki/Win32_Thread_Information_Block

Am 06.09.2013 04:00, schrieb Martin Nowak:
> On 09/01/2013 09:33 PM, Benjamin Thaut wrote:
>>
>> 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.
>
> Yes, it has a bunch of special relocations and runtime linker support
> for this.
> It would be nice if someone could figure out and summarize all the TLS
> index and TIB business on Windows.
>
> http://msdn.microsoft.com/en-us/library/windows/desktop/ms686997(v=vs.85).aspx
>
> http://en.wikipedia.org/wiki/Thread-local_storage#Windows_implementation
> http://en.wikipedia.org/wiki/Win32_Thread_Information_Block

What do we need this information for?

-- 
Kind Regards
Benjamin Thaut

Am 06.09.2013 03:51, schrieb Martin Nowak:
> On 09/01/2013 05:26 PM, Rainer Schuetze wrote:
>>
>> 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.
>>
> Based on your saying that there are no absolute data relocations for
> this on windows we'd have to perform runtime initialization.
> At runtime it would simply copy _imp_var into pvar, right?

Yes. As Rainer already mentioned we can either do this by running some initialiers before initializing druntime, or we could add additional information in a section of the dll and run some generic dll initialization code.

>
>> Do we support the same for pointers in TLS?
>>
>> int* tlsvar = &var;
>>
>> This might need initialization per thread, or patching the original TLS
>> segment.
> No you can't take the address of a TLS var at compile time.

Its not taking a address of a TLS variable. It is initializing a TLS variable with the address of a __gshared variable.


-- 
Kind Regards
Benjamin Thaut

Ok there is a new problem. Consider the following example:

module lib1;

export int lib1Func()
{
  return 5;
}


module lib2;
import lib1;

export int lib2Func()
{
  return lib1Func() + 1;
}


If you compile lib1 into a static library and then copmpile lib2 into a DLL which statically links against lib1 both symbols lib1Func and lib2Func will be exported from the dll because lib1Func will get marked as dllexport when compiled into a static library and the static library transports that information into the linking process of lib2. This happens both on win32 and win64. But this is something you really don't want. Lets imagine you have a DLL that statically links against phobos. Suddenly you will have all phobos exported symbols in your dll. This can also lead to double defined symbols in case a user links against your dll and against the shared phobos dll. So we have to fix this somehow.

I propose that we add a command-line-paramter to the compiler (windows only) which actually enables dllexport. So all behavior described in the DIP will be enabled by default, but to actually make it mark symbols with dllexport you have to specifiy a additional command-line-parameter. We could call it "-dll" or something.

In case you want to try it out yourself, here is the repro case: http://stuff.benjamin-thaut.de/D/dll2.zip

Kind Regards
Benjamin Thaut

On Saturday, 7 September 2013 at 12:47:19 UTC, Benjamin Thaut wrote:
> I propose that we add a command-line-paramter to the compiler (windows only) which actually enables dllexport. So all behavior described in the DIP will be enabled by default, but to actually make it mark symbols with dllexport you have to specifiy a additional command-line-parameter. We could call it "-dll" or something.
>

I have to think about it. But I'd like to avoid any special behavior for windows language side.

I also kind of feel that we need to export lib1 as well, as you may not know what lib2 does with what it gets from lib1 (passing objects around for instance). So certainly at least some part of lib1 need to be exported.

Am 07.09.2013 20:42, schrieb deadalnix:
> On Saturday, 7 September 2013 at 12:47:19 UTC, Benjamin Thaut wrote:
>> I propose that we add a command-line-paramter to the compiler (windows
>> only) which actually enables dllexport. So all behavior described in
>> the DIP will be enabled by default, but to actually make it mark
>> symbols with dllexport you have to specifiy a additional
>> command-line-parameter. We could call it "-dll" or something.
>>
>
> I have to think about it. But I'd like to avoid any special behavior for
> windows language side.
>
> I also kind of feel that we need to export lib1 as well, as you may not
> know what lib2 does with what it gets from lib1 (passing objects around
> for instance). So certainly at least some part of lib1 need to be exported.

I don't agree if that statement. If you have three libs. lib1, lib2 and lib3. And lib2 and lib3 link statically against lib1 you are going to get linker errors because both lib2 and lib3 contain the symbols of lib1. And you don't have any options to avoid that (unless you got into the source of lib1 and remove all export attributes, which might not even be possible because you don't have the source)

On Friday, 6 September 2013 at 02:00:22 UTC, Martin Nowak wrote:
> Yes, it has a bunch of special relocations and runtime linker support for this.
> It would be nice if someone could figure out and summarize all the TLS index and TIB business on Windows.
>
> http://msdn.microsoft.com/en-us/library/windows/desktop/ms686997(v=vs.85).aspx
> http://en.wikipedia.org/wiki/Thread-local_storage#Windows_implementation
> http://en.wikipedia.org/wiki/Win32_Thread_Information_Block

Best material I found on Windows TLS so far: http://www.nynaeve.net/?s=tls

Haven't really looked into the interaction between multiple DLLs at all so far, though.

David

On Saturday, 7 September 2013 at 21:41:01 UTC, Benjamin Thaut wrote:
> I don't agree if that statement. If you have three libs. lib1, lib2 and lib3. And lib2 and lib3 link statically against lib1 you are going to get linker errors because both lib2 and lib3 contain the symbols of lib1. And you don't have any options to avoid that (unless you got into the source of lib1 and remove all export attributes, which might not even be possible because you don't have the source)

And you should have an error, especially is you pass object from one side to the other.

typeid won't match (which will create a mess in the runtime), and worse, struct layout may not match (hello memory corruption).

If the problem is that big, we can still have a -noexport flag or something, but that doesn't seems really safe to me.

On 07.09.2013 14:47, Benjamin Thaut wrote:
> I propose that we add a command-line-paramter to the compiler (windows
> only) which actually enables dllexport. So all behavior described in the
> DIP will be enabled by default, but to actually make it mark symbols
> with dllexport you have to specifiy a additional command-line-parameter.
> We could call it "-dll" or something.

I don't think the issue is Windows specific, symbol visibility in the GNU toolchain is also bound to the declaration. I remember seeing public (visibility=default) symbols exported from static libraries on OSX.