[LLVMbugs] [Bug 18951] New: MS ABI: Implement compatible RTTI

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=18951

            Bug ID: 18951
           Summary: MS ABI: Implement compatible RTTI
           Product: clang
           Version: unspecified
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
          Assignee: unassignedclangbugs at nondot.org
          Reporter: rnk at google.com
                CC: david.majnemer at gmail.com,
                    eldlistmailingz at tropicsoft.com, llvmbugs at cs.uiuc.edu,
                    peter at pcc.me.uk
            Blocks: 12477
    Classification: Unclassified

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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20140224/73e64460/attachment.html>