[PATCH] [ms-cxxabi] Implement vbtable name mangling

[Reid Kleckner]

On Fri, Apr 12, 2013 at 2:42 PM, John McCall <rjmccall at apple.com> wrote:
> On Apr 12, 2013, at 10:59 AM, Reid Kleckner <rnk at google.com> wrote:
>> On Wed, Apr 10, 2013 at 4:12 PM, John McCall <rjmccall at apple.com> wrote:
>>> On Apr 6, 2013, at 3:44 PM, Reid Kleckner <rnk at google.com> wrote:
>>>> +  virtual void mangleCXXVBTable(const CXXRecordDecl *Derived,
>>>> +                                llvm::ArrayRef<const CXXRecordDecl *> BasePath,
>>>
>>> This needs to be a path of CXXBaseSpecifier*s.  One, that's probably
>>> more straightforward to create, and two, there's an ambiguity here that
>>> it'd clean up.
>>
>> Should I be rolling my own recursion here to discover all unique
>> subobjects, or is there some method on CXXBasePaths I should be
>> calling to generate these?
>
> A CXXBasePathElement stores the Base.
>
>>> For example:
>>>  struct A { int x; };
>>>  struct B : virtual A {}; // vbptrs: B
>>>  struct C : virtual B {}; // vbptrs: C, virtual B in C
>>>  struct D : B, C {}; // vbptrs: B in D, C in D, virtual B in D
>>>
>>> Incidentally, how would these actually be mangled?
>>
>> That program gives:
>> error C2584: 'D' : direct base 'B' is inaccessible; already a base of 'C'
>
> Oh, right, yes, sorry.

Re-ordering B and C gets through with a warning instead of an error:
struct A { int a; };
struct B : virtual A { int b; };
struct C : virtual B { int c; };
struct D : C, B { int d; };
D d;

warning C4584: 'D' : base-class 'B' is already a base-class of 'C'

I'm still stumped on the logic for the symbols this produces though:

# B's vbtable for itself
??_8B@@7B@

# C's vbtables, self then for B
??_8C@@7B0@@
??_8C@@7BB@@@

# D's vbtables.
??_8D@@7BC@@@  # vbptr inside C
??_8D@@7B@           # vbptr inside non-virtual B
??_8D@@7BB@@@  # vbptr inside morally virtual B

I would expect this to be mangled as:
??_8D@@7BC@@@  # same
??_8D@@7BB@@@  # because there is ambiguity between B and C
??_8D@@7BB@@C@@@  # same

Adding another level of non-virtual inheritance gives deeper paths:
struct E : D, C, B { int e; };

??_8E@@7BC@@D@@@  # vbptr in C in D in E
??_8E@@7BD@@@     # vbptr in non-virtual B in D in E
??_8E@@7BC@@@     # vbptr in C in E
??_8E@@7BB@@@     # vbptr in non-virtual B in E
??_8E@@7BB@@D@@@  # vbptr in virtual B in C in D in E

It seems weird to me that the symbol for vbtables installed inside
morally virtual bases includes non-virtual path steps.  That means the
symbol depends on which path you follow to find the virtual base.
That said, the path order is fairly obvious.

Any idea what's going on here?  What's special about non-virtual B's
vbtable inside D that makes it's symbol shorter?  Previously I
expected there to be something special about the name of the first
vbtable occurring in non-virtual bases, but this doesn't fit because
the non-virtual B subobject comes after C in D.

I attached the test case that I've been developing.  It's a work in
progress, but it can answer some questions if you're curious.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: microsoft-abi-vbtables.cpp
Type: text/x-c++src
Size: 8999 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130416/c98ff5e2/attachment.cpp>