DIP45: fixing the dllimport/dllexport issue

Martin Nowak code at dawg.eu
Thu Aug 29 13:04:36 PDT 2013


On 08/29/2013 09:28 PM, Benjamin Thaut wrote:
> Well no its not that simple. You can't just alias it. You still have to
> create a import table. That would mean ALL data accesses to data symbols
> would have another level of indirection. Always. The _imp_ symbols don't
> refer to the data directly, they refer to the location the data is
> stored at. As explained in the article I linked
> (http://blog.omega-prime.co.uk/?p=115) this requires different assembly
> to be generated. To make this work we would always have to generate
> assembly with one level of indirection added for every data symbol
> access, because we can not know if the symbol might be imported from a
> DLL or not. As D tries to achive near C++ performance I would arther
> want to avoid that.

So the alias trick would only work for functions.
For data the _imp_* symbol would need to be a pointer to the data?
How about LTO, when statically linking it should be possible to optimize 
away the indirection. Also are there special relocations?

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;
}



More information about the Digitalmars-d mailing list