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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
