[PATCH] D43184: [WIP] [ItaniunCXXABI] Add an option for loading the type info vtable with dllimport

[Reid Kleckner via Phabricator via cfe-commits]

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?


Repository:
  rC Clang

https://reviews.llvm.org/D43184