[cxx-abi-dev] C++ ABI version 2

[Richard Smith]

Hi,

There are a few things in the current ABI which are known to be suboptimal,
but we cannot change because doing so would introduce an ABI break.
However, vendors sometimes get an opportunity to break their ABI (or are
defining a new ABI), and for some vendors, this is a very common
occurrence. To this end, I think it would be valuable for the ABI document
to describe what we might want to put in a 'Version 2' of the ABI; that is,
a set of changes that we recommend be made whenever a vendor has a chance
to introduce an ABI break.

(Or perhaps this should be viewed from the opposite perspective: we could
make improvements to the ABI, with an annex listing changes that old
platforms must make for compatibility.)

Would there be support for this idea?


In off-line discussion with John McCall, we came up with the following list
of potential changes that might be made (sorry if I forgot any):

 * Make constructors and destructors return 'this' instead of returning
'void', in order to allow callers to avoid a reload in common cases and to
allow more tail calls.
 * Simplify case 2b in non-POD class layout.
 * Make virtual functions that are defined as 'inline' not be key functions
 * Fix the bug that -1 is both the null pointer-to-data-member value and
also a valid value of a pointer-to-data-member (could use SIZE_MIN instead)
 * Relax the definition of POD used in the ABI, in order to allow more
class types to be passed in registers

Are there any other things that it would make sense to change in a version
2 of the ABI?


Also, would there be any support for documenting common deviations from the
ABI that platform vendors might want to consider when specifying their own
ABIs? In addition to some of the above, this would also include:

 * Representation of pointers-to-member-functions (in particular, the
current representation assumes that the lowest bit of a function pointer is
unused, which isn't true in general)
 * Representation of guard variables (some platforms use the native word
size rather than forcing this to be 64 bits wide)

Are there any others?


Thanks!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/cxx-abi-dev/attachments/20131119/0e4a0abd/attachment.html>