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



--- Comment #10 from Martin Nowak <code@dawg.eu> 2013-08-29 07:49:41 PDT ---
(In reply to comment #7)
> 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.

I'm not a big of conflating protection and export. For example you could split a library in two DLLs in which case you might need to export/import private and package protected symbols.

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

Can you tell a bit more about this.

-- 
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 #11 from Benjamin Thaut <code@benjamin-thaut.de> 2013-08-29 08:28:06 PDT ---
When a variable is accessed which is linked in through a static library the compiler generates a direct access. If it is linked in through a dynamic library however the compiler needs to generate another level of indirection through the import table. Which is done by referencing _imp_ symbol instead of the original symbol directly. Thats wyh the compiler has to know if the symbol is imported from a dynamic or static library.

-- 
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 #12 from Benjamin Thaut <code@benjamin-thaut.de> 2013-08-29 09:50:15 PDT ---
I found a excelent blog post on this topic, especially the "auto-linking" part of it is interresting:

http://blog.omega-prime.co.uk/?p=115

-- 
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 #13 from Rainer Schuetze <r.sagitario@gmx.de> 2013-08-29 11:07:40 PDT ---
Nice blog post. I have implemented something similar to "auto-import" by adding some additional relocation data for data accesses. At program start the addresses that are relocated to the import table are patched.

Unfortunately this does not work for 64-bit applications, because relocations inside a dmd generated binary are 32-bit pc-relative only. You cannot put the address to a variable insde another DLL there as it might be anywhere in the 64-bit address space and out of reach for the 32-bit relative address.

-- 
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 #14 from Rainer Schuetze <r.sagitario@gmx.de> 2013-08-29 11:12:17 PDT ---
(In reply to comment #10)
> I'm not a big of conflating protection and export. For example you could split a library in two DLLs in which case you might need to export/import private and package protected symbols.

I guess you are referring to "public symbols" only. Actually anything is fine for me, but I guess it doesn't really make sense for private symbols as you are not allowed to access them from another module anyway.

-- 
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 #15 from Martin Nowak <code@dawg.eu> 2013-08-29 11:38:04 PDT ---
(In reply to comment #11)
> When a variable is accessed which is linked in through a static library the compiler generates a direct access. If it is linked in through a dynamic library however the compiler needs to generate another level of indirection through the import table. Which is done by referencing _imp_ symbol instead of the original symbol directly. Thats wyh the compiler has to know if the symbol is imported from a dynamic or static library.

Maybe my understanding of the Windows mechanism is wrong, but I don't think that the exported symbol has to be different. All the runtime binding happens in the import library and which is similar to the PLT for ELF. Code that refers to an imported symbol will then statically link against the import library.

-- 
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 #16 from Benjamin Thaut <code@benjamin-thaut.de> 2013-08-29 11:44:50 PDT ---
> Maybe my understanding of the Windows mechanism is wrong, but I don't think that the exported symbol has to be different. All the runtime binding happens in the import library and which is similar to the PLT for ELF. Code that refers to an imported symbol will then statically link against the import library.

Yes for functions symbols this is true, but data symbols require special handling as described before. What are you trying to suggest with this statement?

-- 
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 #17 from Martin Nowak <code@dawg.eu> 2013-08-29 11:54:03 PDT ---
(In reply to comment #16)
> Yes for functions symbols this is true, but data symbols require special handling as described before. What are you trying to suggest with this statement?

Well, the question is, whether we can annotate symbols with "export" and still create static libraries.

-- 
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 #18 from Benjamin Thaut <code@benjamin-thaut.de> 2013-08-29 11:58:13 PDT ---
> Nice blog post. I have implemented something similar to "auto-import" by adding some additional relocation data for data accesses. At program start the addresses that are relocated to the import table are patched.
> 
> Unfortunately this does not work for 64-bit applications, because relocations inside a dmd generated binary are 32-bit pc-relative only. You cannot put the address to a variable insde another DLL there as it might be anywhere in the 64-bit address space and out of reach for the 32-bit relative address.

A optimization like this would be nice, but walter already stated that he
preferes the classical way (another level of indirection). Maybe we should
first concentrate on the other issues at hand before discussing optimizations.
The most important beeing:
- when does export mean dllimport and when dllexport. Newsgroup discussion
brought up that we could enable dllimport/dllexport per module (including all
submodules) via a command line switch.
- 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)
- Should exporting of entire classes / structs be possible? E.g. marking a
class es export, exports its vtable, typeinfo, all protected / public
functions,
static members, etc.
- Which informations about modules need to be exported? Will they be
automatically exported as soon as the module has a single exported function /
class / variable?

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

-- 
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 #19 from Martin Nowak <code@dawg.eu> 2013-08-29 15:05:57 PDT ---
(In reply to comment #18)
> - when does export mean dllimport and when dllexport. Newsgroup discussion brought up that we could enable dllimport/dllexport per module (including all submodules) via a command line switch.

There are some problems with the current implementation.

export void foo() {} // definition  => dllexport
export void foo();   // declaration => dllimport
export int a = 0;    // definition  => dllexport
export int a;        // declaration => dllimport // fails because it's actually
a definition
export extern int a; // declaration => dllimport

It would be great if we could avoid extra .di headers.

> - 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. http://gcc.gnu.org/wiki/Visibility http://people.redhat.com/drepper/dsohowto.pdf

> - Should exporting of entire classes / structs be possible? E.g. marking a
> class es export, exports its vtable, typeinfo, all protected / public
> functions,
> static members, etc.

Yes, because there is no way to annotate compiler generated data.

Once again please stay away from abusing protection for export because it creates too many problems for future language extensions, e.g. maintaining private symbols for ABI compatibility, module definitions in multiple files/objects, partial classes. Linking and symbol protection are fundamentally different concepts and we should offer orthogonal control.

> - Which informations about modules need to be exported? Will they be automatically exported as soon as the module has a single exported function / class / variable?

Yes, it's hidden compiler data and you might need to link against the ModuleInfo and some other symbols.

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

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