Re: Patch for throw/catch problems

[Jason Merrill <jason_merrill at redhat dot com>]

>>>>> "Jakub" == Jakub Jelinek <jakub@redhat.com> writes:

[discussion of the runtime cost of fixing up all the static references to
RTTI nodes and their NTBS's; Jakub was wondering about making the NTBS's
internal to a shared object]

> On Tue, Aug 14, 2001 at 01:59:42PM +0100, Jason Merrill wrote:
>> I think that when we were discussing this, we failed to consider the
>> runtime initialization impact of our choice.  I seem to remember a
>> message from Intel a while back indicating an effect on EH code as well.
>> 
>> Jakub: The code relies on the ZTS nodes being shared between shared
>> objects.  We cannot rely on all references to a type using the same ZTI
>> node; in particular, we do something different for incomplete types.

> Do you have some testcase which shows this? I see _ZTS nodes being put
> into _ZTI constructor in just one place only in cp/rtti.c.

I was confused; only pointers to incomplete types are represented
differently.

>> However, I would think the ZTI nodes could be made hidden.

> If that would be true, even better (I believe there are more relocs against
> _ZTI* symbols than relocs against _ZTS* symbols).
> But http://reality.sgi.com/dehnert_engr/cxx/abi.html#vtable
> says:

> The typeinfo pointer points to the typeinfo object used for RTTI. It is
> always present. All entries in each of the virtual tables for a given class
> must point to the same typeinfo object. A correct implementation of typeinfo
> equality is to check pointer equality, except for pointers (directly or
> indirectly) to incomplete types. The typeinfo pointer is a valid pointer for
> polymorphic classes, i.e. those with virtual functions, and is zero for
> non-polymorphic classes.

> which suggest that typeinfo compare should compare typeinfo pointers, not
> __name fields.

FYI, the official website for the ABI is now 

  http://www.codesourcery.com/cxx-abi/

but it says the same thing.  I believe that this is a case of obsolete
wording; since we decided to commonize the NTBS, there is no reason to
allow implementations to rely on being able to compare the type_info node
addresses directly.  We certainly handle type_info comparison by looking at
the NTBS address; would anyone object to new wording to disallow comparison
of type_info node addresses?

Jason