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

John McCall rjmccall at apple.com
Wed Apr 10 13:12:03 PDT 2013

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.

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?

> +bool CXXRecordDecl::hasDirectVirtualBase() const {
> +  for (CXXRecordDecl::base_class_const_iterator I = this->bases_begin(),
> +       E = this->bases_end(); I != E; ++I) {
> +    if (I->isVirtual())
> +      return true;
> +  }
> +  return false;
> +}
> +

I really doubt you actually need this.

> +      // If Base is the only non-virtual base of its parent, we can skip this
> +      // link in the path and still guarantee that this is a unique symbol.
> +      if ((*I)->getNumBases() == 1 && !(*I)->hasDirectVirtualBase())
> +        continue;

This is just ((*)->getNumBases() == 1 && !(*(*I)->bases_begin())->isVirtual()),
but I'm very skeptical about this computation.

The deep question here, which I can't really answer myself without seeing
tests, is when, exactly, MSVC adds base-path information to the mangling?
If I were designing this, I would add it only when a class has multiple non-virtual
bases, and I would only add it to "secondary" vb-tables — i.e. to vb-tables that
are not the "primary" vb-table, i.e. not the one that I would add the new entries
to if my class added new virtual bases.  And I'd need some way to distinguish
paths that correspond to morally virtual base sub-objects, e.g. to handle my
test case above.


More information about the cfe-commits mailing list