mstorsjo added a comment. Ping @rnk - let me reiterate the questions that are open:
In https://reviews.llvm.org/D43184#1009355, @rnk wrote: > Here's a case where a local vtable would help: > > struct __declspec(dllimport) A { virtual void a(); }; > struct __declspec(dllimport) B { virtual void b(); }; > struct __declspec(dllimport) C : A, B { > void a() override; > void b() override; > }; > constexpr C c; > > > I'm suggesting we can make a DSO local copy of _ZTV1C, so that we can refer > to it from `c`. It's OK if the vtable refers to the imported thunks, since > the address of virtual methods isn't user visible. > > Either that, or we need to make something like this change here, right? Ok, I see - I think this should be doable the way you suggest, but I haven't done any further work on that yet. However I unfortunately don't think this can solve the class_type_info case at all: For `__cxxabiv1::__class_type_info`, there's no declaration visible in scope at all, and the actual contents of the vtable of this class (and the other similar classes) doesn't seem to be defined in the ABI (it seems to differ significantly between libc++abi and libsupc++). Or do you have any idea of how to work around that as well? We could emit an empty local vtable and try to initialize that at runtime by copying from the dllimported real vtable - but I guess we don't even know the size of it, when its members are defined by the c++abi implementation. So in case this approach as my hacky PoC does is the only feasible way left, I obviously need to fix it up. Any directions and suggestions on how to structure it properly? And suggestions for the user visible option, etc? In https://reviews.llvm.org/D43184#1005281, @smeenai wrote: > FYI, binutils auto-import actually creates a fake IAT entry rather than using > a dynamic initializer. I think it's actually a pretty cute trick. > http://blog.omega-prime.co.uk/2011/07/04/everything-you-never-wanted-to-know-about-dlls/#how-auto-import-works > has details. That only works when you're referencing an external imported > symbol directly though, and breaks when you need an offset from the imported > symbol. Actually, it feels like that blogpost is rather outdated; I can't manage to make current binutils produce this form of fixups for the issue at all. What it does however, is create a runtime pseudo relocation; the linker generates extra info in the rdata section about the relocations it wasn't able to handle, which the mingw crt will fix up on startup before handing control over to the end user code. This can involve changing the protection of the code sections to writeable in order to do such fixups there. (This feature has been in binutils since 2002.) 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
