[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#1031831, @mstorsjo wrote:

> 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.


I see, the field layout of the RTTI is defined by the ABI, but the vtable layout is an implementation detail of the C++ ABI runtime.

> 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?

Well, I guess it's the equivalent of /MD /MT, i.e. is your CRT static or dynamic. How is this expressed to GCC?

> 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.)

So basically mingw has a custom relocation format layered on top of PE. I mean, that would certainly help code size. Otherwise, every TU that emits a vtable with RTTI is going to need a dynamic initializer... that would be bad for startup time, unless we have clever ways to dedupe them across TUs.

Maybe the cleaner thing to do is to actually handle this as a relocation. I tried to figure out what GCC is doing, but it doesn't seem to work at all.



================
Comment at: lib/CodeGen/ItaniumCXXABI.cpp:3218
+    // Run with priority 0, before any user defined ctors
+    CGM.AddGlobalCtor(Fn, 0);
+  }
----------------
I was surprised to discover that this probably works. I'd forgotten that mingw rolls its own .ctors section instead of reusing some of the .CRT$XCU machinery. This just makes me feel like we're layering the levels of paper deeper, and we might be better off implementing the mingw relocation thingy you mentioned.


Repository:
  rC Clang

https://reviews.llvm.org/D43184