RTTI portability

[Jim Dehnert]

> From nathan at codesourcery.com Tue Oct 17 01:31:43 2000
> 
> Jim Dehnert wrote:
> 
> > 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.
> 
> Yup, though I'd been assuming that allowing user access, was just allowing
> read access to those fields, or the creation of objects of types within
> the abi heirarchy. Allowing that would not create a problem.
> 
> Whether we permit users to derive from those types is a different question,
> and would create difficulty with the current spec. Do we really want to do
> that too?
> 
> We could allow read access to compiler generated type_info objects, and
> prevent user creation/derivation of those types by making the dtors
> private in the most derived types, and protected in the intermediate ones.

Someone's confused here (it might be me).  The problem with user access
arises if (and only if, I believe) the user (a) makes the reference
using a header file for the type_info structures that is not an
accurate description of the runtime library actually present on the
target system when his program runs, and (b) the fields referenced are
in different places in the two versions.  This can happen with either
data member references (if data members have been added or deleted), or
with virtual function references (if virtual functions have been
changed, or other vtable layout changes have occurred).  Users deriving
types may be more likely to have problems since their new members will
go at the end of the structures, but any reference is subject to a
potential problem if the vendors rearrange the structure by adding
members.

The key observation is that user references generally start with a
fixed offset based on the compiler's view of the class declarations in
the header file, not on the actual runtime structure used by the
library.

In fact, since the user creates RTTI structures for user types, this
may be an issue even if there are no explicit references to the members
in the user source, if any data members change.

So it seems to me that we must at least require that the data members
not change between implementations, which allows their names to be
normative if we like.  We need not make any requirements about virtual
functions, unless we allow users to call them, or to derive from the
classes.  Does anyone think we should not forbid this?

Am I confused?  I know the above discussion didn't arrive at quite the
place I expected when I started...

> > 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.
>
> Yes, I think we'd better ...

Upon looking, we already say so (in 1.4.1).



> From loewis at informatik.hu-berlin.de Tue Oct 17 04:40:48 2000
> From: Martin von Loewis <loewis at informatik.hu-berlin.de>
> 
> > 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.
> 
> Indeed. I see no advantage of adding an implementation defined field
> over allowing implementation-defined virtual functions.

The advantage is that it allows the implementation some flexibility
with absolutely no modification of the RTTI class or its virtual table.
Perhaps it's not an important advantage...


> From: Martin von Loewis <loewis at informatik.hu-berlin.de>
> 
> > > 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.
> 
> Why is that a concern? If a user inherits from abi::pointer_type_info,
> what undesirable effects could come out of that?

If the definition doesn't match what's in the library at runtime, and
he creates a vtable that isn't correct that ends up being referenced by
the runtime library, he won't be a happy camper.

> I was more concerned about having the compiler-provided code in a
> static library which then gets integrated into somebody's shared
> library (as gcc's libgcc.a gets integrated into every shared library,
> likewise libCrun.a and libCstd.a of Sun CC).

As noted above, the vendor libcxa.so is required to be a DSO.  If you
integrate a non-shared library into your program, there are no
portability guarantees.

> > 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.
> 
> Used in the sense of being accessed - yes, why not? However, I would
> not expect users ever to create typeinfo objects.

They will certainly create typeinfo objects, for their user-defined
classes.

> > 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.
> 
> The problem is that there is a difference between system libraries and
> the C++ runtime library - those typically come with the C++ compiler,
> not (necessarily) with the system.

Yes, I suppose this is ambiguous.  View the "system" as the runtime C++
system, including the target processor support and the C++ support
being used on top of it.  The latter will most often come from the
system vendor, but might not, e.g. g++.


So, after all the above, I suggest the following actions:

- Remove the statement that data member names are not normative.

- Add a statement that the data members must be exactly as specified.

- Leave the statement that the user may not reference the virtual
  functions.  (Since the destructor is virtual, does this effectively
  forbit deriving from the classes?)

Does this create problems for anyone?

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