DIP45: fixing the dllimport/dllexport issue

[Rainer Schuetze]

On 29.08.2013 23:40, Martin Nowak wrote:
> On 08/29/2013 10:17 PM, Benjamin Thaut wrote:
>>> How about LTO, when statically linking it should be possible to optimize
>>> away the indirection.
>>
>> Rainer Schuetze stated that some linkers are capable of doing this
>> optimizations. But I don't know aynthing further about this topic.
>>
>>>
>>> module libA;
>>> export int var;
>>> int* _imp_var = &var; // created by compiler
>>>
>>> module foo;
>>> import libA;
>>>
>>> void bar()
>>> {
>>>      auto val = var; // creates val = *_imp_var;
>>> }
>>>
>>
>> Yes that would work. Still there must be a reason why microsoft doesn't
>> do stuff like that in their C++ toolchain. Its certanly going to cost
>> performance.
> I just tested it and it works.
>
> lib.c
>
> int var = 0xdeadbeaf;
> int* _imp_var = &var;
>
> main.c
>
> #include <stdio.h>
>
> extern int* _imp_var;
> void main()
> {
>      printf("%d\n", *_imp_var);
> }
>
> cl /c /O2 /GL lib.c
> cl /O2 /GL main.c lib.obj
>
> get objconv from http://www.agner.org/optimize/
>
> objconv -fasm main.exe
>
> Search for deadbeaf in main.asm to get the symbol number (?_1176).
> It directly loads the variable.
>
> mov edx, dword ptr [?_1176]

It's a bit easier to see the code by adding debug symbols and using 
dumpbin /disasm main.exe.

Unfortnately, this won't help us a lot, because the intermediate object 
files have some unknown format and in fact are just transferring some 
code representation to the linker that then invokes the compiler and 
optimizer on the full source code. This is very specific to the C/C++ 
toolchain and I don't think we can take advantage of it.