[cxx-abi-dev] C++ ABI version 2
Jason Merrill
jason at redhat.com
Mon Aug 1 18:15:11 UTC 2016
On Wed, Jul 20, 2016 at 8:24 PM, 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.
> Of course, the va_list option can still be presented.
>
That was the plan when the ABI was developed, but AFAIK nobody has actually
implemented it.
> [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
>
>
>
>
> _______________________________________________
> 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/20160801/ae6d7153/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/20160801/ae6d7153/attachment.gif>
More information about the cxx-abi-dev
mailing list