On Wed, Jul 20, 2016 at 8:24 PM, Hubert Tong <[email protected]> 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 <[email protected]> > To: "[email protected]" <[email protected]> > Date: 19-07-2016 09:04 p.m. > Subject: Re: [cxx-abi-dev] C++ ABI version 2 > Sent by: [email protected] > ------------------------------ > > > > 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 <*[email protected]* > <[email protected]>> 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 <*[email protected]* > <[email protected]>> 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 > [email protected] > http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev > > > > > _______________________________________________ > cxx-abi-dev mailing list > [email protected] > http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev > >
_______________________________________________ cxx-abi-dev mailing list [email protected] http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev
