Virtual Calls: Make the ABI match the implementations

[Jim Dehnert]

Having read through all the mail on this subject now, I think it
reflects a fundamental erroneous assumption, namely that weak symbols
will yield to strong symbols.  That is mostly true on Irix and Linux,
but not on most other SVR4 implementations, and not even on Irix and
Linux for delay-loaded DSO objects.  Most (all?) of them do that
within a linked object, but once an object has been linked, the
distinction between the two disappears, and the first one in search
order is the one used when the program runs.  (This is true of SCO and
AIX, and I thought of HPUX and Compaq, though the base ABI discussion
of this was a year ago.)  That means that if the definitions are spread
over DSO boundaries, the callsite definition (weak COMDAT) will
override the "primary" definition with the class (strong non-COMDAT) if
it comes first.  And since that will normally occur as a result of the
class definition being in a library being used by the caller's module,
this will be the rule rather than the exception.  So a "pure weak"
model (i.e. Irix/Linux where weak always yields)

This might be OK, if (a) it helped implementors a lot, and (b) there
was a clear transition path to the desired endpoint.  But (b) presents
a serious problem.  Even an optimized implementation that emits the
thunks where they "belong" must continue to also emit them with the
callers as long as there exist implementations which don't supply them
with the class definitions, and therefore must suffer sub-optimal
results even for their own code if they don't use the pure weak model.
And as long as the sub-optimal model is considered ABI-compliant, we'll
continue to have it indefinitely.

As for being easier to implement, I just don't see it.  The thunks are
trivial bits of code (worse perhaps if you fall through, but that's not
required).  Compared to the other changes we've required, this one
seems real minor.

> From: Mark Mitchell <mark at codesourcery.com>
> 
> Perhaps.  Christophe and I came up with this suggestion because it
> doesn't actually remove any of the benefits of the innovation.  For
> example, allowing virtual bases to be primary is a major change in
> everyone's compilers -- but it does also provide a big win for some
> code.  By simply mandating that compilers put out the old-style
> thunks, we'd cost only space in .o's -- a good compiler can override
> with the new-style thunks (modulo the linker issue you raised), and
> then the final executable will be precisely the same as currently
> specified.

As I explained above, this isn't true.  Most of the Unix systems out
there treat weak symbols like strong ones once they're linked.

> So, all we're suggesting is easing things for implementors without
> limiting the performance gains from the ABI at all.
> 
> It's not that -- it's the fact that the thunks you have to emit have a
> pretty different form from the usual thunks.  They have to look at
> vcall offsets too -- not just make the usual single this adjustment.

I guess I don't understand this comment.  Whether the thunk has to look
at the vcall offset doesn't have anything to do with where it's
emitted.  If you want to emit a thunk with a hard-coded offset, that's
OK by the as-if rule, in either place.

> The reason this particular issue is coming up (as opposed to, say,
> vcall offsets or virtual bases as priamry bases) is that it tends to
> impact compiler back-ends much more than most of our other changes.
> In a lot of organizations, the back-ends are much more separate from
> the front-ends than they are in GCC -- for example, maintained by an
> entirely different group with different management.  Interfaces
> between front-ends and back-ends have to change, optimizers have to be
> revalidated, all tools that process the back-end representation have
> to be recompiled, etc.

Why?  The thunk is just another (rather simple) function.  The front
end should be able to produce it in its intermediate language if that's
desirable, and leave the back end blissfully unaware.

Jim

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