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

[John McCall]

On Feb 17, 2013, at 4:38 PM, Gabriel Dos Reis <gdr at integrable-solutions.net> wrote:

> On Sun, Feb 17, 2013 at 3:58 PM, Jason Merrill <jason at redhat.com> wrote:
>> On 02/16/2013 08:58 PM, John McCall wrote:
>>> 
>>> GCC stopped even uniquing _ZTS's by
>>> default as of GCC 4.5, using a new comparison scheme on all platforms
>>> (which, incidentally, I think would be worth documenting as an official
>>> alternative, if anyone from GCC would mind describing the rules they use).
>> 
>> 
>> _ZTSs are no less unique now than they were before; we just accepted that
>> RTLD_LOCAL prevents reliably uniquing symbols.  For data that really needs
>> to be unique such as template static data members, we introduced
>> STB_GNU_UNIQUE, but we decided that it was too expensive to use for _ZTSs,
>> so we left them only mostly unique, and started doing string comparison
>> instead of pointer comparison.  For types local to a translation unit we
>> still do pointer comparison.
>> 
>> Jason
> 
> John, I believe it is a reasonable thing to ask for *amendment* to the
> ABI to get
> the leeway you would like to get -- though I suspect the wording would be more
> involved than what I've seen so far.
> 
> However, we can't pretend that the ABI never asked for uniqueness of these
> artefacts or that nobody depended on them.

Gaby, I'd to clarify again that I am not actually proposing that we do
anything about the uniqueness of RTTI objects (_ZTSs and _ZTIs),
despite the widespread divergence.  The widespread divergence is a
problem that we need to address eventually, because it does seriously
affect the interoperation of compilers, but it's not why I'm posting now.

I am currently seeking consensus that we never meant to guarantee
uniqueness of *v-tables* (_ZTVs and _ZTTs).  I thought this would be
uncontroversial.  If it isn't, then I agree that I should come back with a
more formalized proposal.

I do know that there's code out there which loads and compares v-table
pointers — for example, WebKit's JavaScript engine used to do that,
although IIRC those types had key functions.  Of course, that code has
to either perform undefined behavior (by accessing the byte representation
of a polymorphic class) or escape the guarantees of the standards (by
using assembly), so I'm not too concerned about it, especially since many
existing compilers don't currently guarantee the uniqueness of v-tables
in all cases anyway (e.g. across dynamic library boundaries).

John.