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

Thu Jul 21 13:59:29 UTC 2016

Alternative function entry points seem like too much of a burden on the
compiler implementing the ABI. I'm not sure how I would transliterate that
to C either. Translating va_start to va_copy in variadic virtual functions
with a covariant return type seems much simpler to me.

On Wed, Jul 20, 2016 at 8:33 PM, Hubert Tong <hstong at ca.ibm.com> wrote:

> ... and I can record the adjustments necessary as a pointer to a function.
>
> -- HT
>
> [image: Inactive hide details for Richard Smith ---20-07-2016 08:30:52
> p.m.---On 20 July 2016 at 17:24, Hubert Tong <hstong at ca.ibm.com>]Richard
> Smith ---20-07-2016 08:30:52 p.m.---On 20 July 2016 at 17:24, Hubert Tong <
> hstong at ca.ibm.com> wrote: > I believe at least the covariant
>
> From: Richard Smith <richardsmith at google.com>
> To: Hubert Tong/Toronto/IBM at IBMCA
> Cc: "cxx-abi-dev at codesourcery.com" <cxx-abi-dev at codesourcery.com>
> Date: 20-07-2016 08:30 p.m.
> Subject: Re: [cxx-abi-dev] C++ ABI version 2
> ------------------------------
>
>
>
> On 20 July 2016 at 17:24, Hubert Tong <*hstong at ca.ibm.com*
> <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*
>    <richardsmith at google.com>>
>    To: "*cxx-abi-dev at codesourcery.com* <cxx-abi-dev at codesourcery.com>" <
>    *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*
>    <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* <cxx-abi-dev at codesourcery.com>
> *http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev*
>    <http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev>
>
>
>
>
>
>
> _______________________________________________
> 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/20160721/89a7ba4e/attachment.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/20160721/89a7ba4e/attachment.gif>