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

[Hubert Tong]

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.

-- HT



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> 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!

_______________________________________________
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/0b1b6fdc/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/20160720/0b1b6fdc/attachment.gif>