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

[Richard Smith]

Another item for the list:

Variadic virtual functions with covariant return types are currently
problematic: it's not possible in general to generate an adjustor thunk for
them, because it's not possible in general to forward a (non-tail) varargs
call. Similar problems exist for the conversion to function pointer in a
non-capturing varargs lambda.

We can fix this by changing the calling convention for varargs non-static
member functions so that they are passed a va_list object directly (that
is, effectively put the va_start / va_end into the caller, and convert a
va_start in the callee into a va_copy from the va_list argument). Then
forwarding the varargs become trivial.

(It seems preferable to apply this change to all non-static member
functions, not just virtual functions, so that we don't need to emit two
quite different codepaths for a call through a pointer to member.)

On 12 May 2015 at 17:29, Richard Smith <richardsmith at google.com> wrote:

> Another item for the Itanium C++ ABI version 2 list:
>
> The ABI currently specifies that the initial guard variable load is an
> acquire load (3.3.2, "An implementation supporting thread-safety on
> multiprocessor systems must also guarantee that references to the
> initialized object do not occur before the load of the initialization flag.
> On Itanium, this can be done by using a ld1.acq operation to load the
> flag.").
>
> This is inefficient on systems where an acquire load requires a fence.
> Using an algorithm due to Mike Burrows (described in the appendix of
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2008/n2660.htm) the
> same interface can be implemented starting with a relaxed load, where the
> acquire operation is performed only the first time each thread hits the
> initialization.
>
> On 19 November 2013 at 17:57, Richard Smith <richardsmith at google.com>
> wrote:
>
>> 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/20160719/24141344/attachment.html>