http://d.puremagic.com/issues/show_bug.cgi?id=9816

           Summary: Export is mostly broken
           Product: D
           Version: D2
          Platform: All
        OS/Version: Windows
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: code@benjamin-thaut.de


--- Comment #0 from Benjamin Thaut <code@benjamin-thaut.de> 2013-03-26 00:28:56 PDT ---
Created an attachment (id=1203)
repro case

Here is a list of all things wrong with export:

32 & 64 bit issues:
1) Exporting a global variable leads to a linker error
2) Exporting thread local variables should be an error (at least it is in c++)
3) The module info should be exported as soon the module has any exported
symbols
4) __gshared members of a class are not exported
5) The TypeInfo Object of the TestClass is not exported
6) The TypeInfo Object of TestStruct is not exported

See attached repro case. If this repro case actually compiles and runs dll support should be sufficient to support a shared runtime.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=9816


Martin Nowak <code@dawg.eu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |code@dawg.eu


--- Comment #1 from Martin Nowak <code@dawg.eu> 2013-04-06 19:05:59 PDT ---
(In reply to comment #0)
> Created an attachment (id=1203) [details]
> repro case
> 
> Here is a list of all things wrong with export:
> 
> 32 & 64 bit issues:
> 1) Exporting a global variable leads to a linker error
What error?
> 2) Exporting thread local variables should be an error (at least it is in c++)
Yes.
> 3) The module info should be exported as soon the module has any exported
> symbols
> 4) __gshared members of a class are not exported
Bug.
> 5) The TypeInfo Object of the TestClass is not exported
> 6) The TypeInfo Object of TestStruct is not exported
> 
Any compiler generated symbol referenced by an exported symbol should be exported too, e.g. ModuleInfos, TypeInfos, opEquals and such.

> See attached repro case. If this repro case actually compiles and runs dll support should be sufficient to support a shared runtime.
Nice.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=9816



--- Comment #2 from Martin Nowak <code@dawg.eu> 2013-04-06 21:12:36 PDT ---
(In reply to comment #1)
> (In reply to comment #0)
> > 2) Exporting thread local variables should be an error (at least it is in c++)
> Yes.
Actually no, at least ELF supports linking/accessing a TLS value of another
shared library.
AFAIK Windows also uses an index per DLL for TLS access so it should be
possible to link/relocate against them.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=9816



--- Comment #3 from Martin Nowak <code@dawg.eu> 2013-04-07 21:32:10 PDT ---
(In reply to comment #0)
> 1) Exporting a global variable leads to a linker error

The problem seems to be that export uses C like rules to distinguish
declarations and definitions. For declarations export means
__declspec(dllimport) and for definitions __declspec(dllexport).

export void foo();   // this treated as import
export void foo() {} // this treated as export

For global variables to be an export you need an initializer.

export __gshared int bar;     // this treated as import export __gshared int bar = 0; // this treated as export

I don't think that rule makes sense as it's actually defining a variable and is
default initalized.
To mark a declaration-only extern should be used.

Furthermore this behavior always requires a header file with only declarations for any importing module.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=9816



--- Comment #4 from Martin Nowak <code@dawg.eu> 2013-05-28 09:31:31 PDT ---
> 1) Exporting a global variable leads to a linker error
fixed by bug 10059

> 2) Exporting thread local variables should be an error (at least it is in c++)

Can't you link against a DLL containing the definition of a thread local variable?

> 3) The module info should be exported as soon the module has any exported
symbols

Makes sense to me.

> 4) __gshared members of a class are not exported
fixed by bug 10059

> 5) The TypeInfo Object of the TestClass is not exported
> 6) The TypeInfo Object of TestStruct is not exported

If a user defined type is exported all compiler-generated metadata, vtables, TypeInfo, RTInfo!Type etc., should be exported too.

I'm not positive if exporting a UDT should imply that all it's members are exported too.

To add export annotations in druntime/phobos we need to fix bug 922.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=9816



--- Comment #5 from Benjamin Thaut <code@benjamin-thaut.de> 2013-05-29 06:21:17 PDT ---
> Can't you link against a DLL containing the definition of a thread local
variable?

I can. But I thought that it is better to make something an error it is hard to implement and maybe later allow it then to allow it and not implement it.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=9816



--- Comment #6 from Benjamin Thaut <code@benjamin-thaut.de> 2013-05-29 06:22:40 PDT ---
Sorry, I wanted to say that I'm not sure if it is possible to make thread local variables work across dll boundaries so I think we should make it a error first and might be able to allow it later.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=9816


Rainer Schuetze <r.sagitario@gmx.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |r.sagitario@gmx.de


--- Comment #7 from Rainer Schuetze <r.sagitario@gmx.de> 2013-08-27 00:07:48 PDT ---
A few random comments:

- I think in a situation where you want to use the same code for static and dynamic linking, "export" is not usable. I'd propose to export every public symbol at module granularity depending on a compile switch.

- but then, there is no easy way to tell whether symbols in a module are imported from a static or dynamic library. This distinction is necessary though, as the code is different for both situations. Maybe a versioned pragma at module level can control this.

- Using TLS variables from other DLLs is possible, but probably not with the current tool chain. What needs to be exported is the offset of the symbol in the TLS section and the address of the _tls_index variable in the DLL that exports the symbol. The code to read the variable could then look like this

  mov EAX,[_imp_variable.tls_index]; // read address of tls_index in import
table
  mov EAX,[EAX]; // read tls_index of DLL
  mov EBX,FS:[2C]; // tls_array
  mov EBX,[EBX+4*EAX]; // tls_start of DLL
  mov ECX,[_imp_variable.offset]; // read offset of variable in TLS of DLL
  mov EDX,[EBX+ECX]; // read variable

If the offset is not exportable, _tls_start is also needed for the DLL.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=9816



--- Comment #8 from Benjamin Thaut <code@benjamin-thaut.de> 2013-08-27 09:41:35 PDT ---
Wouldn't it be easier to implement a getter function for each TLS variable which just returns the address of the variable value?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=9816



--- Comment #9 from Rainer Schuetze <r.sagitario@gmx.de> 2013-08-28 23:29:36 PDT ---
Your're right, a function would be simpler. It might be a little less efficient because of the indirect jump, but avoids the two indirect data accesses through the import table.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------