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

[John McCall]

On Nov 22, 2013, at 1:16 AM, Anthony Williams <anthony at justsoftwaresolutions.co.uk> wrote:
> On 21/11/13 18:32, John McCall wrote:
>> On Nov 21, 2013, at 12:24 AM, Anthony Williams <anthony at justsoftwaresolutions.co.uk> wrote:
>>> On 20/11/13 01:57, Richard Smith 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.
>>> 
>>>> Are there any other things that it would make sense to change in a
>>>> version 2 of the ABI?
>>> 
>>> If people are willing to make an ABI change, it would be great if they
>>> could add in the necessary information to allow std::current_exception
>>> to take a copy of the exception rather than increasing the reference
>>> count on the existing exception.
>> 
>> You should not expect that anybody is going to make an ABI change
>> to an existing platform.
> 
> I don't: that much was made quite clear at the WG21 meeting where this
> was discussed.
> 
> However, I don't think it's unreasonable for version N+1 of a platform
> to extend the ABI in this way. Precompiled code written for version N
> would continue to run, but code compiled for version N+1 could take
> advantage of the new ABI. I expect I could come up with a change that
> worked nicer than my quick patch if I put some time into it.
> 
> Isn't the point of a "version 2 ABI" that it is different to version 1?
> Richard introduced it above as "a set of changes that we recommend be
> made whenever a vendor has a chance to introduce an ABI break.”

Right, of course it’s something that we could do given an ABI break.
What I’m saying is that the scenario that you just described...

> Precompiled code written for version N
> would continue to run, but code compiled for version N+1 could take
> advantage of the new ABI.


...is not an ABI break; version N+1 of a platform is still required to
interoperate with version N.  None of the other changes we’re discussing
would permit binary interoperation.

An ABI break is more like what Apple just had when we ported iOS to ARM64:
we didn’t have any binary compatibility requirements with previous versions
of iOS on ARM64, so we were completely free to change the ABI.

> This is a change I would like to see under such circumstances.

If you’d like to make a concrete proposal for a revised ABI, you’re welcome to,
and we can debate it then.  However, before we can, we really need to
understand the language feature we’d be implementing; it seems to be
somewhat underspecified.

For starters, [propagation]p8 does not define how the exception should be
copied on implementation that do perform this copy.  I presume that you'd
like it to be copied as if from a const l-value.  However, we do not appear
to be authorized to introduce a use of such a constructor; [except.throw]p5
only authorizes the compiler to check access to the constructor that would be
used to initialize the exception object from the throw operand, and in C++11,
that will often be a move constructor.

Also, substituting std::bad_exception just because we don’t know how to
copy the exception, as opposed to because copying the exception actually
failed, does not actually appear to be authorized.  The standard should define
the desired behavior when the copy constructor is non-const, inaccessible,
or defined as deleted.

John.