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

[Gabriel Dos Reis]

On Fri, Feb 15, 2013 at 8:19 PM, Richard Smith <richardsmith at google.com> wrote:
> 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."

Indeed, this appears to be more than a decade old issue

     http://gcc.gnu.org/ml/gcc/2002-05/msg01970.html

Beware: the discussion was very long; the details can be found in the archive.

-- Gaby


>
>>
>> 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
>
>
>
> _______________________________________________
> cxx-abi-dev mailing list
> cxx-abi-dev at codesourcery.com
> http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev
>