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

[Michael Gschwind]

On Wed Nov 20 05:33:31 UTC 2013, John McCall <rjmccall at apple.com> wrote 
: 
| On Nov 19, 2013, at 5:57 PM, Richard Smith <richardsmith at google.com> 
wrote:
| > 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?
| 
| Personally, I’m in favor of us generally documenting any vendor-specific 
deviations, as long as the vendor’s okay with it.  In principle, that list 
of deviations could get unmanageably long, but I doubt it’d be a real 
issue.
|
| > 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):
| > 
| >  * Simplify case 2b in non-POD class layout.
|
| >  * 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.
| >  * Make virtual functions that are defined as 'inline' not be key 
functions
| 
| Credit the good folks at ARM for these two ideas.

I am curious about the history here, because it seems that the AArch64 ARM 
ABI appears to drop these changes?  Does anybody have an explanation what 
transpired to make ARM reconisder and go back to a more vanilla 
"industry-standard ABI" (aka Itanium ABI)? 

Did it turn out that the improvements to be gotten (e.g., by shaving off a 
few cycles for reloading this) just wasn't worth the cost of deviating 
from the center of gravity for the C++ ABI that everybody else had, or can 
we infer more substantial reasons?  (I think there may still be a few 
testcase fails for ARM32b due to different name mangling etc.)

Also, the  iOS ABI on 32b ARM seems to have stepped back from the full 
scope of the ARM 32b ABI?   Any thoughts what is pulling these ABIs back 
into the  mainline?


On Nov 21, 2013, at 12:41 AM, Marc Glisse <marc.glisse at inria.fr> wrote:
> On Wed, 20 Nov 2013, John McCall wrote:
>> Well, to be clear, these would be recommendations for people willing to 
endure an ABI break.  That would still be a big NO-NO for any established 
platforms that care about binary compatibility.
>> 
>> And most of these changes are pretty minor improvements; the ABI has 
really held up very well.
> 
> Indeed.

Not only that, but it appears that those who departed on the occasion of 
an ABI break seem to have come back into the fold on the next ABI break?

Mike

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/cxx-abi-dev/attachments/20131126/49633a11/attachment.html>