emitting vtables (was rtti data layout notes)

[Jim Dehnert]

OK, I've added a comment about this to the ABI layout document --
please see if it looks OK, everyone.  But beyond that, do we assume
that all references to any function members of these classes are in the
library, and therefore inherently consistent, or do we need to define
the function member interface, too?

> From sidwell at codesourcery.com  Wed Feb  2 02:25:51 2000
> 
> Jim Dehnert wrote:
> > 
> > One more response from the meeting:
> > 
> > > Date: Mon, 24 Jan 2000 10:17:28 +0000
> > > From: Nathan Sidwell <sidwell at codesourcery.com>
> > >
> > > 2) place of emission of vtables.
> > > The vtables for the type_info derrived classes must be in the runtime.
> > > Other translation units must not emit vtables. Rationale: the runtime
> > > will expect certain implementation defined virtual member functions
> > > for these classes. A foreign translation unit must not override the
> > > runtime's vtable.
> > 
> > The perspective from the meeting was why not?  That is, if the class
> > has a virtual function, either (a) the user deriving from it needs to
> > override the vfunc for some reason and should be able to, or (b) the
> > user shouldn't override it because it's not appropriate, and is
> > responsible for avoiding the problem.  This stuff is in the
> > implementation name space, so it shouldn't be happening by accident.
> > Let the user beware if he trespasses...
> Oops, I've been careless with terminology. My apologies.
> 
> I didn't mean the case of a user deriving from (say) __fundamental_type_info,
> which as you say might be dangerous -- the ABI only defines the data
> layout for __fundamental_type_info and leaves unspecified any additional
> virtual member functions the implementation may add.
> 
> I was worried that a translation unit emitting the __class_type_info
> definition for `struct Foo' (for example), might have the freedom
> of also emitting the vtable for __class_type_info. Naturally that
> would be a disaster, as there's no knowledge of the runtime support
> internals that the translation unit happens to be linked with. 
> 
> I now see that closed issue B-5 (sort of) covers this. What is left
> unspecified is that implementations must assume that __class_type_info
> has at least one non-inline virtual function. As it stands at the moment,
> compiler implementation A is free to have a runtime support definition
> of __class_type_info with no non-inline virtual member functions.
> Therefore, when that compiler emits the __class_type_info object for
> `struct Foo', it must emit the vtable for its definition of __class_type_info.
> Of course, that translation unit might be linked with the other modules and
> the runtime of implementation B, which has a different definition of
> __class_type_info.
> 
> I suspect that all implementations will end up having such a virtual
> function, but it would be prudent to say so.
> 
> nathan
> 
> -- 
> Dr Nathan Sidwell :: sidwell at codesourcery.com
> nathan at acm.org  http://www.cs.bris.ac.uk/~nathan/  nathan at cs.bris.ac.uk
> 
-	    Jim Dehnert		dehnert at sgi.com
				(650)933-4272