rnk added a comment.

In https://reviews.llvm.org/D43184#1005161, @majnemer wrote:

> Do I understand correctly that this workarounds a feature missing in lld? 
> Does MinGW emit the same sorts of object files as clang in these scenarios?

You can see it that way, but having the linker synthesize a dynamic initializer 
to initialize dllimport data seems a bit heroic to me. MSVC link doesn't do it. 
It requires making assumptions about how your C runtime runs dynamic 
initializers. Your DLL might not even link msvcrt, so how does the linker know 
where to put the initializer?

On the other hand, you can be assured that users will ask us for this bfd 
linker feature indefinitely if we don't implement it. It papers over 
differences between the COFF and ELF object models, and mingw usually papers 
things over rather than pushing the cost onto ELF-oriented codebases.

Clang already creates dynamic initializers for stuff like:

  __declspec(dllimport) int imported;
  int *const pi = &imported;
  int foo() { return *pi; }

So, it doesn't seem like a bridge too far to make dynamic initializers for 
globals with vtables. It's dicey, though. It means there's a point in your 
program when your vptr is null. =/

Do you think we should do something like local vftables for itanium instead? 
Can we assume all methods in the vtable will be exported by the DLL exporting 
the class?

  rC Clang


cfe-commits mailing list

Reply via email to