incomplete rtti

Jim Dehnert dehnert at baalbek.engr.sgi.com
Tue Mar 28 23:11:03 UTC 2000


> Date: Sun, 26 Mar 2000 10:16:34 +0100
> From: Nathan Sidwell <nathan at codesourcery.com>
> 
> Hi,
> 
> I'm again puzzled as to how the new rtti scheme is supposed to work
> with incomplete types. There's a contradiction in the layout doc. The
> contradiction is understandable if you know what the intention is, but
> I think it'd be confusing to someone reading this cold (it's still
> confusing to me).
> 
> * `Assuming that after linking and loading only one type_info
>   structure is active'.
> * `Two abi::__pointer_type_info objects are compared for equality (i.e.
>   of the types represented) by checking for equal target type RTTI
>   pointers unless either or both have the incomplete flag set, in
>   which case the pointed-to RTTI structures must be checked for
>   equality (described below).'

I've tried to clarify the first of these.  Take a look.  But...

> The former is refering to complete types. As any `T cv *' is a complete
> type, to test for equality of such a type only requires pointer
> comparison of the type_info's representing that type. It is when
> determining the equality of the targets for differently qualified `T cv
> *' instances with incomplete T that we have to deal with multiple
> instances of the __class_type_info for T. This type of comparison is
> only of interest when looking for a qualification conversion on catch
> matching. It is only the pointer to T which needs to consider this, a
> pointer to pointer to T will not need to know about the completeness of
> T.

This assumption is untrue.  The problem is that weak types don't work
like you assume on most systems.  With the exception of Linux and Irix,
most systems do not distinguish between weak and "strong" symbols once
an object is linked.  Therefore, given a weak RTTI in the main
executable and a strong RTTI in a DSO, they would preempt the latter
with the former.  As a result, it is necessary to make our incomplete
class RTTI not just weak, but distinct.  Once it is distinct, the
pointer RTTI referencing it must be distinct from one referencing the
complete version, and so on up the pointer chain, and it is not
possible to compare them at any level.

Our solution is to use the ABI-defined external mangled RTTI name only
for complete types.  RTTI generated for pointer-to-incomplete-type must
be different.  We leave it to the implementation to decide how, but two
workable approaches are (a) make it a local static, or (b) mangle it
differently and use COMDAT to remove duplicates; but at least one
incomplete RTTI would remain, and it would not be the same as the
complete one even after preemption.

> So why does the __pointer_type_info class's incomplete target type
> (0x8) apply when the ultimate non-pointer type is incomplete? I think
> it should just apply when the immediately pointed-to type is
> incomplete. 
> 
> Secondly I don't see how making the incomplete class type object static
> linkage will avoid preemption. Suppose translation unit 1 contains
>         struct A;
>         ...
>         typeid (A *);
> and unit 2 contains
>         struct B {};
>         struct A : B {};
>         ...
>         typeid (A *);
> 
> The `typeid (A *)' objects emitted in 1 and 2 will have comdat linkage
> and so only one will be active in the final program. We have no control
> over which is actually selected by the linker (I don't think the linker
> cares, because it is assuming that any comdat's named the same have the
> same contents - yes?). Now, which of the abi::__class_type_info's for A
> will the selected one point to? For this to work it must be the one in 2,
> as that contains the complete information about the type. Will static
> linkage of 1's instance behave this way? We need to specify that 1's
> instance has weak linkage.

I hope this helps clear up the confusion.

Jim


-	    Jim Dehnert		dehnert at sgi.com
				(650)933-4272




More information about the cxx-abi-dev mailing list