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

Thu Jul 21 00:30:42 UTC 2016

On 20 July 2016 at 17:24, Hubert Tong <hstong at ca.ibm.com> wrote:

> I believe at least the covariant return case can be solved with
> alternative function entry points which record the adjustments necessary on
> return.
>
A constant adjustment is not sufficient if you're converting to a virtual
base.

> Of course, the va_list option can still be presented.
>
> -- HT
>
> [image: Inactive hide details for Richard Smith ---19-07-2016 09:04:25
> p.m.---Another item for the list: Variadic virtual functions wit]Richard
> Smith ---19-07-2016 09:04:25 p.m.---Another item for the list: Variadic
> virtual functions with covariant return types are currently
>
> From: Richard Smith <richardsmith at google.com>
> To: "cxx-abi-dev at codesourcery.com" <cxx-abi-dev at codesourcery.com>
> Date: 19-07-2016 09:04 p.m.
> Subject: Re: [cxx-abi-dev] C++ ABI version 2
> Sent by: cxx-abi-dev-bounces at codesourcery.com
> ------------------------------
>
>
>
> 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*
> <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*
>    <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*
>    <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!
>
> _______________________________________________
> cxx-abi-dev mailing list
> cxx-abi-dev at codesourcery.com
> http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/cxx-abi-dev/attachments/20160720/d30b8f53/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://sourcerytools.com/pipermail/cxx-abi-dev/attachments/20160720/d30b8f53/attachment-0001.gif>