[PATCH] Fix linkage for vtables of class template specializations with explicit instantiation declarations

John McCall rjmccall at apple.com
Fri Feb 15 16:56:02 PST 2013


On Feb 15, 2013, at 4:54 PM, Richard Smith <richard at metafoo.co.uk> wrote:
> On Fri, Feb 15, 2013 at 4:34 PM, John McCall <rjmccall at apple.com> wrote:
> On Feb 14, 2013, at 8:07 PM, Richard Smith <richard at metafoo.co.uk> wrote:
> > If a class template specialization has an explicit instantiation declaration and needs a VTT, we currently emit all the vtable data as linkonce_odr. That causes link failures in some cases, because recent g++ versions put all the vtable-related data in a COMDAT, and if we emit some of the symbols but not all of them, we can cause the COMDAT from the explicit instantiation definition to not be chosen, resulting in missing symbols.
> >
> > This patch fixes that and removes some FIXMEs by switching us to available_externally. However, testing that fix revealed another problem: if (through inlining and constant propagation through the VTT) we end up with a reference to a construction vtable in the generated code, we will sometimes have no definition for that construction vtable. This is because the Itanium ABI does not require a compiler to emit construction vtables with any particular mangling or linkage, and indeed recent versions of libstdc++.so make all the construction vtable symbols internal.
> >
> > So this patch makes two changes:
> > 1) Emit externally-available primary vtables and VTTs as available_externally rather than linkonce_odr, and
> > 2) Emit externally-available construction vtables as internal rather than linkonce_odr.
> >
> > I believe point (2) conforms to the ABI -- while we're required to use the same primary vtable for all objects of the same most-derived type, the same restriction does not appear to apply to construction vtables.
> 
> Er, I don't remember (and can't find) a requirement that all objects of the same most-derived type must use the same non-construction virtual table group, and I can't think of what would rely on that guarantee.  That would invalidate a number of optimizations we do, e.g. the optimization where we give linkonce_odr v-tables and RTTI objects (but not RTTI names) hidden visibility.
> 
> I was referring to Itanium ABI, 2.5.1, first paragraph: "There may be multiple virtual tables for a particular class, if it is used as a base class for other classes. However, the virtual table pointers within all the objects (instances) of a particular most-derived class point to the same set of virtual tables."

Hmm, missed that.  I'll send mail to cxx-abi-dev about removing that "requirement".

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130215/15ca0677/attachment.html>


More information about the cfe-commits mailing list