... and I can record the adjustments necessary as a pointer to a function.
-- HT From: Richard Smith <[email protected]> To: Hubert Tong/Toronto/IBM@IBMCA Cc: "[email protected]" <[email protected]> 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 <[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. 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 <[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]> 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 < [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
