[LLVMbugs] [Bug 17738] New: [-cxx-abi microsoft] Support vtordisp thunks

[bugzilla-daemon at llvm.org]

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

            Bug ID: 17738
           Summary: [-cxx-abi microsoft] Support vtordisp thunks
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
          Assignee: unassignedclangbugs at nondot.org
          Reporter: timurrrr at google.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

This ABI tries hard to avoid "virtual this adjustment". It's not always
possible though.

Consider the following example:
-------------
  struct A {
    virtual void f();  // Expects "(A*)this" in ECX
  };
  struct B : virtual A {
    virtual void f();  // Expects "(char*)(B*)this + 12" in ECX
    virtual ~B();      // Might call f()
  };
----
B::f assumes that the class layout is |BA| and uses static "-12" this
adjustment in the prologue.

However, if a class overrides a virtual function of its base and has a
non-trivial ctor/dtor that call this virtual function (or may escape "this" to
some code that might call it), a virtual adjustment might be needed, in case
the current class layout and the most derived class layout are different.

For example, in this class:
  -------------
  struct C : virtual B {
    virtual void f();
  };
  -------------
the layout is |CAB|.
If f() is called during B ctor or dtor, the thunk that's stored in B's the
vftable should apply a "+4+12" this adjustment so B::f() gets the right value
of this in the prologue. The extra adjustment is not needed if B is the most
derived class, i.e. the exact adjustment should be determined dynamically. The
value of the dynamic adjustment is stored in the hidden vtordisp associated
with the A vbase, hence the thunk is called a "vtordisp thunk".

-- 
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/20131030/de00b8a1/attachment.html>