[cxx-abi-dev] C++ ABI version 2
Hubert Tong
hstong at ca.ibm.com
Thu Jul 21 00:33:29 UTC 2016
... and I can record the adjustments necessary as a pointer to a function.
-- HT
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> 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
Inactive hide details for Richard Smith ---19-07-2016 09:04:25
p.m.---Another item for the list: Variadic virtual functions witRichard
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> 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/6e862dbd/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/6e862dbd/attachment.gif>
More information about the cxx-abi-dev
mailing list