Re: Why don't we just FIX the damn vthunk problem?

[Jason Merrill <jason at cygnus dot com>]

>>>>> Jason Eager <jce2@po.cwru.edu> writes:

 > After all, it's not like a problem that hasn't been solved before...  It
 > is a BIG problem when a compiler doesn't create valid code no matter how
 > "obscure" the feature may be (and anyone who wants to enjoy the full
 > benefits of C++ will probably use multiple inheritence sooner or
 > later..

The problem only occurs if you call virtual functions from constructors of
virtual bases, which seems a bit odd to me, but I agree it should be fixed.

 > Are there any design documents for egcs? I'll just start working on
 > implimenting vthunks..but I'd be interested to hear about approaches
 > that you've thought of for implimenting the vthunks....

The static way, which EDG and IBM use, is to write out separate [cd]tor
vtables along with the normal ones and pass them down into base [cd]tors.
Obviously, this means you use more space in the executable.

If you don't do this, you need to communicate the offset to the thunks
somehow.  One way would be to create additional thunks on the stack that
adjust for the appropriate offset, then jump to the old thunks.  This would
be the most similar to gcc's non-thunk solution, but it requires support
for putting code on the stack, like gcc trampolines.  Also, like the
non-thunk solution, it makes constructors for objects with vbases larger
and slower.

Another way, which Microsoft uses, is to store the offset just before the
vbase subobject so that the thunk can find it and adjust appropriately.
This adds a bit of space to each vbase subobject.  More importantly,
Microsoft has a patent on it, so it is not an option for us.

Any other ideas?

Jason