MS ABI: Implement compatible RTTI #19325
Comments
|
assigned to @majnemer |
|
For the non-zero offset, it would be really nice if we could reuse COMDATs and alias support in the IR. The idea is to represent it with:
|
|
Are comdats worth the complexity? What's the best idea we have for representing them in LLVM IR? I asked this on IRC, and people generally wanted to be able to represent them, but nobody knew what it would look like. My strawman would look like COFF's IMAGE_COMDAT_SELECT_ASSOCIATIVE, where everyone in the comdat group points to one 'key' symbol. Any key would not be allowed to be associative, which would avoid multi-level structures and cycles. We could also use comdat groups in LLVM IR to fix #17333 , which is one-time dynamic initialization of linkonce data. However, it wouldn't use the llvm.global_ctors array. It would have to use a special section instead. |
|
Beginnings of a symbol_offset diff |
We want them so we can implement constructors and destructors in the same way as gcc, so that is way it would be nice to use it for this too. They are also needed for some corner cases of the ABI that we currently get wrong. See the thread at http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-November/044927.html for the details.
The only "design" I ever did on it is on http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-November/045524.html. So something like @_ZN1UI1SE1kE = weak_odr constant i32 42, align 4, comdat _ZN1UI1SE1kE
Looks about the same to ELF.
|
|
COMDATs landed in r211920. |
|
mentioned in issue #19404 |
|
mentioned in issue llvm/llvm-bugzilla-archive#20106 |
Extended Description
We already have lots of issues about "cannot mangle RTTI descriptors for type 'foo'", but most of them have been resolved with workarounds:
http://llvm.org/bugs/show_bug.cgi?id=18332
http://llvm.org/bugs/show_bug.cgi?id=17403
This issue covers implementing compatible RTTI that works with the implementation the the Microsoft C++ runtime.
This will require changes to LLVM IR. We will need a new linkage type to represent IMAGE_COMDAT_SELECT_LARGEST, and we will need a way to represent a non-zero symbol offset.
MSVC produces vftables where a pointer to RTTI data is at slot -1 in the vftable. They use a scheme that appears to carefully attempt to allow mixing of TUs with and without RTTI, so long as RTTI is never used on classes that are never constructed in a TU with RTTI enabled. Forcing emission of the constructor and therefore vftable will cause emission of RTTI data.
First, the vftable is placed into a COMDAT section with IMAGE_COMDAT_SELECT_LARGEST. The idea is that the vftable with RTTI enabled will be larger and therefore win.
However, once you deduplicate an RTTI vftable with a no-RTTI vftable, all offsets from the vftable symbol in no-RTTI TUs will be off by one slot. To solve this problem, the vftable symbol actually points to the first vftable slot that contains a pointer to a virtual method. We can't represent this in LLVM IR today. Implementing this will require something like symbol_offset proposed here:
http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-April/061511.html
There are a couple of alternatives, like "place_before", but we don't have COMDAT groups in LLVM IR, which makes this awkward.
For symbol_offset, the preferred design so far is one where the offset is handled by the MC layer, and is ignored by GVN and GlobalOpt. In other words, GEPing to the 0th field of a vftable would give you the RTTI data. When we LTO a binary with mixed RTTI TUs, the linker would be required to look at the symbol offset and fix up the GEPs.
The text was updated successfully, but these errors were encountered: