emitting vtables (was rtti data layout notes)

[Nathan Sidwell]

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