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

[John McCall]

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

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.