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

[John McCall]

On Nov 28, 2013, at 9:53 AM, Michael Wong <michaelw at ca.ibm.com> wrote:
> cxx-abi-dev-bounces at codesourcery.com wrote on 11/19/2013 08:57:50 PM:
> > From:
> > 
> > Richard Smith <richardsmith at google.com>
> > 
> > To:
> > 
> > "cxx-abi-dev at codesourcery.com" <cxx-abi-dev at codesourcery.com>, 
> > 
> > Date:
> > 
> > 11/19/2013 08:58 PM
> > 
> > Subject:
> > 
> > [cxx-abi-dev] C++ ABI version 2
> > 
> > Sent by:
> > 
> > cxx-abi-dev-bounces at codesourcery.com
> > 
> > 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.
> 
> This seems like a simple idea, but does it save extra calls in every case for the cost of the ABI breakage? I think I can think of a few cases where it will save, but can there be cases where it won't save?

It never saves a call.  It can avoid some stack traffic, which has the pleasant side effect of decreasing code size.  There’s also a distant possibility of allowing the call to the constructor or destructor to be emitted as a tail-call, if the function that calls the constructor just immediately returns a pointer to the constructed object (as a normal pointer, not a smart pointer — a smart pointer would be non-POD and therefore returned indirectly).

> Do we think we will implement this using another set of differently named C1,C2, C3, D1,D2,D3 to make sure that we know which one return this and which one return void, otherwise how do implementations tell the difference between the old set and the new set?

Constructors that return ’this’ and constructors that don't shouldn’t ever co-exist.  You should be able to know from the target whether constructors and destructors make this guarantee.

> >  * Simplify case 2b in non-POD class layout.
> I could not track down what the simplify proposal is in the ARM C++ ABI.

It’s not in the ARM C++ ABI.  It follows a footnote in the main ABI.

> Is this saying we will remove the complication of the search for the Nearly-Empty base which causes such headache for implementers 10 years ago? But now that we all have it, is it worth the few weeks that it would take to pull it out. For us, this code is fairly infused into the whole primary base search mechanism. Is this simplification something else?

I believe the simplification is to remove the clause ", or just the first one if they are all indirect primaries”.  A nearly-empty virtual base that is not an indirect primary would still be a candidate for primary base.

> >  * Make virtual functions that are defined as 'inline' not be key functions
> 
> While I like this change because it removes a persistent ambiguity, my question is do the majority of compilers pick the base that does not have the out-of-class inline keyword (i.e. the first virtual void f()). We still pick the out-of-class inline one (the virtual void b()) that is not declared inlined in the class. This is clearly IMHO against the spirit of the key function, but don't all compilers do the same thing and if so, why change it? May be it is better to change the definition to define precisely what everyone already do and just leave it as a wart?

The ABI *does* require that; it says "the first non-pure virtual function that is not inline at the point of class definition”.

The change would be to say “the first non-pure virtual function that is not inline”.  So after processing the class definition, you might think that foo() is the key function, but then you see an inline definition of foo() and realize it isn’t.

This works because the language requires virtual functions with inline definitions to be defined in every translation unit that defines the class.  So the compiler’s idea of what the key function is might change as it processes a translation unit, but it should still reach the same conclusion in every translation unit, because it’s required to see the exact same set of inline definitions.

This change does have the potential to break programs that aren’t technically compliant, though.

> >  * 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)
> 
> This is the one I would probably pick to like the most if someone can show me the ambiguous case. I just could not think of it. Aren't all the offset to base always positive? Since you said it exists, I believe you so I just want to see what it is and if so I would agree the fix is needed.

I think the only legal examples are all really convoluted.

> >  * 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?
> 
> Do we want to specify how dynamic Thread local storage is done? As some can do it using a Compiler guard, while others can do it through a new OS section making it non-interopearable?

I think we actually worked that out on the list; it just hasn’t made it into the document yet.  (I’d happily add it if someone wouldn’t mind drafting a patch.)

John.