Re: C++ PATCH: ABI bug for vcall offsets

[Mark Mitchell <mark at codesourcery dot com>]

> Excuse an uninformed question.  But does that mean, that it now is
> possible that one accidentially breaks binary compatibility when adding
> virtual functions (or overwriting them) and accidentially swapping some
> decls?
Adding completely new virtual functions has always broken binary
compatibility; it changes the layout of vtables.

Overriding a virtual function can indeed cause ABI changes, but that is
not new with this change.  The use of vcall offsets in general means
that new overriders change the number of vcall offsets present in the
vtable.

The ABI was designed this way because Jason invented vcall offsets. :-)
Jason cleverly figured out a way to figure out what thunks you needed
before seeing all final overriders, which has the potential to improve
performance when calling through a thunk.  We could have had vcall
offsets for all functions, as a way of making adding overriders without
breaking binary compatibility, but that would have been costly in terms
of space.

The shorter answer is "because this way goes fastest" and that the
ability to add functions was considered not nearly as important as
performance.

--
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com