RTTI portability

[Jim Dehnert]

> From nathan at codesourcery.com Fri Oct 13 02:08:24 2000
> 
> > A program that is built from pieces from different compilers, where the
> > pieces come from different implementations of the hierarchy, will see
> > different structures, at least in the vtables, if we allow this extra
> > material to be arbitrary, creating a problem if such programs actually
> > make use of parts of the hierarchy.
>
> What is being meant by `used' here? It is only the vtables that will be
> different, and then the implementation parts will be in the later
> parts of the vtable. Thus accessing the std defined entry points will
> work across compilers. Do you mean
>
> A) a user program derives from abi::pointer_type_info and then attempts
> to use objects of that class within the type_info system?
>
> B) parts of the program other than those in libcxa.so attempt to use
> the implentation defined entry points?

I am concerned about both.

> I think A is user error and B is only possible with Martin's example below.

That solution implies a statement that the non-Standard-defined parts
of the hierarchy are not available to users.  Fine with me, but someone
wanted to make the field names in the hierarchy normative, which has no
point unless they expected them to be used outside the target runtime.
In the absence of allowing user access, you're right -- there's no
problem.

> >   First, observe that the vtables for the typeinfo derived classes will
> >   be emitted where the key function (the virtual destructor, as
> >   defined) is defined.  We require this to be in the implementation's
> >   runtime library libcxa.so, so there is exactly one implementation of
> >   them on any given target system.
>
> One of Martin's concerns was about creating a library FOO with
> `ld -Bsymbolic' against one compiler's libcxa.so, and then ultimately
> using that library in an executable with a different compiler's libcxa.so.
> FOO will contain copies of the first compiler's implementation of the
> type_info vtables and implementation functions. If we are to permit
> such a library, we have to guarantee that there are no implementation
> defined parts of the vtable _or_ type_info instances.

It is a traditional part of the SysV ABI that libc is _always_ a DSO.
I presume that we're extending that assumption to libcxa, though I
guess we'd better say so.

I personally believe that anyone who links the system libraries into
their program is tying his program to a particular implementation, and
had better use only pieces from that implementation (if it's supported
at all, which I wouldn't, and SGI traditionally hasn't).  So, ... no
problem.

> >   We allow the implementation to define a collection of pseudo-virtual
> >   functions to be associated with each class derived from std::type_info:
> ...
> >   Construction of one of the std::type_info derivatives can either call
> >   the constructor or use the mangled name to initialize the __aux
> >   member.
> > 
> >   Use of __aux is reserved to the runtime implementation.
>
> How does this help? Given Martin's -Bsymbolic example we'd just get
> different versions of __cxa_aux_type_info in FOO and the runtime. The
> same problem would still be manifest.

It only helps if you're assuming user access to the type_info
hierarchy.  In that case, the virtual functions at the low end of the
hierarchy will shift those at the high end in the vtable.  If you
forbid user access, the problem goes away.

Jim

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