[cxx-abi-dev] There is no obligation to unique virtual tables

Richard Smith richardsmith at google.com
Sat Feb 16 02:19:17 UTC 2013


On Fri, Feb 15, 2013 at 5:38 PM, John McCall <rjmccall at apple.com> wrote:

> Richard Smith has pointed out to me that the ABI document currently
> states, right at the beginning of section 2.5:
>
>   A virtual table (vtable) is a table of information used to dispatch
> virtual functions, to access virtual base class subobjects, and to access
> information for runtime type identification (RTTI). Each class that has
> virtual member functions or virtual bases has an associated set of virtual
> tables. 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.
>
> This last sentence could be interpreted as a strict requirement that all
> objects of a most-derived class use the same v-table, as opposed to
> potentially a private copy of that v-table.
>
> While it is obviously good to avoid redundant copies of a v-table in
> memory, an unconditional requirement to do so seems excessive.  Uniquing a
> symbol with vague linkage across dynamic-library boundaries may require a
> significant amount of work, probably at load time but at best at the first
> use of the symbol (a sort of laziness which would carry its own
> disadvantages).  This work is required for the RTTI symbol name (_ZTS*) in
> order to make RTTI comparison work, but it is not otherwise mandatory for
> the RTTI object (_ZTI*) or v-tables (_ZTV*) or VTT (_ZTT*).
>

It is currently mandatory for the _ZTI, per 2.9.1:

"It is intended that two type_info pointers point to equivalent type
descriptions if and only if the pointers are equal. An implementation must
satisfy this constraint, e.g. by using symbol preemption, COMDAT sections,
or other mechanisms."


> In practice, it is quite common for compilers to implement optimizations
> that decrease the visibility of symbols when the uses of them are not
> address-sensitive, or as requested by users.  I would hate for this to be a
> violation of the ABI.
>
> I propose changing (clarifying?) this paragraph to conclude as follows:
>   However, the virtual table pointers within all the objects (instances)
> of a particular most-derived class point to the same **logical** set of
> virtual tables, **although they need not in fact have pointer-equivalent
> addresses or contents**.
>
> I say "contents" because referencing a function in a v-table is not an
> address-sensitive use of it.  In fact, it is impossible to construct an
> address-sensitive use of a virtual function in standard C++, since
> pointer-to-members for virtual functions refer to the virtual "slot", not
> the concrete implementation.
>
> John.
> _______________________________________________
> cxx-abi-dev mailing list
> cxx-abi-dev at codesourcery.com
> http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/cxx-abi-dev/attachments/20130215/111a199d/attachment.html>


More information about the cxx-abi-dev mailing list