<html>
<head>
<base href="http://llvm.org/bugs/" />
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW --- - MS ABI: Implement compatible RTTI"
href="http://llvm.org/bugs/show_bug.cgi?id=18951">18951</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>MS ABI: Implement compatible RTTI
</td>
</tr>
<tr>
<th>Product</th>
<td>clang
</td>
</tr>
<tr>
<th>Version</th>
<td>unspecified
</td>
</tr>
<tr>
<th>Hardware</th>
<td>PC
</td>
</tr>
<tr>
<th>OS</th>
<td>Windows NT
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>P
</td>
</tr>
<tr>
<th>Component</th>
<td>LLVM Codegen
</td>
</tr>
<tr>
<th>Assignee</th>
<td>unassignedclangbugs@nondot.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>rnk@google.com
</td>
</tr>
<tr>
<th>CC</th>
<td>david.majnemer@gmail.com, eldlistmailingz@tropicsoft.com, llvmbugs@cs.uiuc.edu, peter@pcc.me.uk
</td>
</tr>
<tr>
<th>Blocks</th>
<td>12477
</td>
</tr>
<tr>
<th>Classification</th>
<td>Unclassified
</td>
</tr></table>
<p>
<div>
<pre>We already have lots of issues about "cannot mangle RTTI descriptors for type
'foo'", but most of them have been resolved with workarounds:
<a class="bz_bug_link
bz_status_NEW "
title="NEW --- - CL : error : cannot mangle RTTI descriptors for type 'codecvt' yet"
href="show_bug.cgi?id=18332">http://llvm.org/bugs/show_bug.cgi?id=18332</a>
<a class="bz_bug_link
bz_status_RESOLVED bz_closed"
title="RESOLVED FIXED - VS wrapper: "cannot mangle RTTI descriptors for type 'error_category'""
href="show_bug.cgi?id=17403">http://llvm.org/bugs/show_bug.cgi?id=17403</a>
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:
<a href="http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-April/061511.html">http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-April/061511.html</a>
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.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>