[cxx-abi-dev] comparing type_infos (was Re: Patch for throw/catch problems)

[Jakub Jelinek]

On Tue, Aug 14, 2001 at 03:42:46PM +0100, Jason Merrill wrote:
> >>>>> "Jason" == Jason Merrill <jason_merrill at redhat.com> writes:
> 
> > 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?
> 
> It occurs to me that even if we do this, we need to consider the case of a
> polymorphic class for which we only emit the vtable, and thus the
> type_info, in one place.  The type_info would still need to be addressable
> from outside the shared object where it is defined, though we could bind
> strongly within the shared object.
> 
> Or we could change gcc to always generate type_infos wherever referenced; I
> believe that would be conformant, though I'm not sure it would be a win.

This should be no problem if NTBS are private to each library and type_infos
unique accross the whole program, if NTBS' are only referenced from type_infos
with the same name (Jason, does your "only pointers to incomplete types are
represented differently" mean this condition is always satisfied?).
Then it really does not matter if you compare type_info pointers or their
NTBS'.
Without any kind of prelinking, it would probably be better to have
type_infos private and NTBS COMDAT during run-time linkining, but with
prelinking this kills some optimization possibilities (particularly removing
unneeded NTBS conflicts). If NTBS are private and type_infos COMDAT, then
prelinker can optimize by seeing if a particular type_info is never used
(because its symbol is preempted by some other one earlier in the search
path) and just avoid the relocation of that type_info structure.

I don't know how could we make _ZTI symbols GLOBAL/WEAK while making
relocations against them be resolved at static link time to that symbol,
unless we special cased this in the linker, which is not a good idea IMHO.

	Jakub