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
_______________________________________________ cxx-abi-dev mailing list [email protected] http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev
