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

[John McCall]

On Apr 16, 2013, at 6:42 AM, Reid Kleckner <rnk at google.com> wrote:
> 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'

Hah.  I don't think that's an extension we need to stress over supporting.

> 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.

How dependent are the manglings on each other?  Like, if you remove
the direct 'B' base here, do any of the other manglings change?

John.