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



--- Comment #20 from Martin Nowak <code@dawg.eu> 2013-08-29 15:37:26 PDT ---
(In reply to comment #19)
> > > Well, the question is, whether we can annotate symbols with "export" and still create static libraries.
> > 
> > At the moment: no. But we should create a solution where this very case will work. Proposed solution. 'export' is always a no-op unless you specifiy otherwise using a command line switch to the compiler.
> 
> That sounds like a reasonable solution when we can't do better. Also see the alias discussion on the newsgroup http://forum.dlang.org/post/kvo9gm$8fs$1@digitalmars.com.

That wouldn't work in the case where you create a DLL that both exports symbols and imports symbols from another 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 #21 from Martin Nowak <code@dawg.eu> 2013-08-29 19:29:11 PDT ---
To summarize the alias proposal.
For every exported function definition we also emit an alias symbol
_imp_funcname.
For every exported data definition we emit a weakly linked read-only pointer T*
_imp_var = &var.

Whenever an exported symbol is called or accessed this is done using the _imp_*
symbol.
When such code gets linked with an import library it will correctly work with a
DLL.
When such code gets linked with a static library it will reference the correct
definitions.
The simple export attribute is sufficient for all use-cases, no worries about
dllimport/dllexport/no-op.
If we were able to use whole program optimization the linker could optimize
away the additional data access indirection when linking statically.

I don't think the last point is too critical because exporting data is rarely
done and rather a bad practice.
Also this only applies to the API boundary which shouldn't be a performance
hotspot.

For ELF export should simply make a symbol visible, otherwise symbols should be hidden by default.

Any ideas about Mach-O? Same as ELF?

-- 
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 #22 from Rainer Schuetze <r.sagitario@gmx.de> 2013-08-29 23:40:47 PDT ---
(In reply to comment #19)
> > - do we want a export all public symbols feature (discussion on the newsgroup brought up that c++ is trying to move away from this, maybe we should too)
> 
> Please let's try to go into the other direction on Unix too. You can find more about the reasoning here.

Do you want to annotate all of phobos and druntime with "export" to build a shared version? I think we are already in annotation hell with nothrow, pure, @safe, etc...

-- 
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 #23 from Martin Nowak <code@dawg.eu> 2013-08-29 23:59:07 PDT ---
(In reply to comment #22)
> Do you want to annotate all of phobos and druntime with "export" to build a shared version? I think we are already in annotation hell with nothrow, pure, @safe, etc...

Yes, that's what I intend. Doing this manually is important, because exporting a symbol means commiting to ABI stability, which should be a longterm goal. Because exported symbols are the known entry points of a library this reopens the question whether we could use much more inference for non-exported symbols.

-- 
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 #24 from Benjamin Thaut <code@benjamin-thaut.de> 2013-08-30 00:32:50 PDT ---
> I don't think the last point is too critical because exporting data is rarely
> done and rather a bad practice.
> Also this only applies to the API boundary which shouldn't be a performance
> hotspot.

The digital mars linker is not capable of doing so. Also as stated on the newsgroup we will most likely not be able to use LTO of the mircosoft linker. Also this will not only affect to API bounadries, it will affect all accesses to global data: __gshared variables, shared variables, and all compiler internal global data symbols like module info, type info, vtables, etc. This is because without knowing what symbols are imported from a DLL we have to add the indirection to all of them. If we decide to use the alias solution we would have to accept the additional level of indirection for all global data accesses and keep in mind that this is most likely going to stay that way for a long time.

> Yes, that's what I intend. Doing this manually is important, because exporting a symbol means commiting to ABI stability, which should be a longterm goal. Because exported symbols are the known entry points of a library this reopens the question whether we could use much more inference for non-exported symbols.

I fully agree here. We might still want to provide a -exportall switch for convenience.

-- 
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 #25 from Benjamin Thaut <code@benjamin-thaut.de> 2013-08-30 00:45:28 PDT ---
> That wouldn't work in the case where you create a DLL that both exports symbols and imports symbols from another DLL.

It would work. Because the command line switch to the compiler would specifiy a module name, so it won't turn all 'export' into dllexport. E.g. if you build phobos you would add "-export std" to the command line of the compiler. This would turn all 'export' inside any of the std modules into dllexport. So this would work very for DLLs that both export and import symbols. For dllimport there would be a equivalent command line switch e.g. "-import std" which needs to be specified when linking against a shared phobos library. These command line switches could then be added to the default sc.ini so users don't have to specify them manually.

-- 
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 #26 from Martin Nowak <code@dawg.eu> 2013-08-30 05:11:45 PDT ---
(In reply to comment #24)
> > I don't think the last point is too critical because exporting data is rarely
> > done and rather a bad practice.
> > Also this only applies to the API boundary which shouldn't be a performance
> > hotspot.
> 
> The digital mars linker is not capable of doing so. Also as stated on the newsgroup we will most likely not be able to use LTO of the mircosoft linker. Also this will not only affect to API bounadries, it will affect all accesses to global data: __gshared variables, shared variables, and all compiler internal global data symbols like module info, type info, vtables, etc. This is because without knowing what symbols are imported from a DLL we have to add the indirection to all of them.

No! This only applies to data that is marked as export. So you do know quite well what could be imported.

-- 
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 #27 from Martin Nowak <code@dawg.eu> 2013-08-30 05:26:36 PDT ---
And the metadata of exported UDTs (vtable, rtti) and moduleinfos for modules with exported members. Also note that because Windows doesn't support symbol interposition it's safe to access the data directly from within a 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 #28 from Martin Nowak <code@dawg.eu> 2013-08-30 06:07:52 PDT ---
(In reply to comment #24)
> I fully agree here. We might still want to provide a -exportall switch for convenience.

A compiler switch makes sense for the case where you have the source
code but don't want to modify it, e.g. a downloaded package that was
not annotated. Here it might make sense to offer -export=public,package,private
because nobody maintains the ABI anyhow.

(In reply to comment #27)
> And the metadata of exported UDTs (vtable, rtti)

Actually not vtables because they are indirectly addressed through the class instance already.

-- 
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 #29 from Benjamin Thaut <code@benjamin-thaut.de> 2013-08-30 07:49:43 PDT ---
> No! This only applies to data that is marked as export. So you do know quite well what could be imported.

You are correct, I didn't take into account that we can leverage export in that way.

The only question remaining is, how big the performance impact is when doing cross DLL calls. When the compiler knows that the function is located inside a DLL it can directly generate a jmp. If it doesn't know it, it has to call the function stub which itself does the jmp. That means using this aliasing all cross DLL function call would have a additional call instruction overhead. If you use a object oriented API this overhead should be minimal because most function calls go through vtables anyway. But how big is it for functional libraries, like phobos?

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