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

[Gabriel Dos Reis]

On Mon, Feb 18, 2013 at 12:47 PM, John McCall <rjmccall at apple.com> wrote:
> 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.

OK.

-- Gaby

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