[cxx-abi-dev] Library ABI version markers

[Richard Smith]

On 24 September 2014 10:59, Jason Merrill <jason at redhat.com> wrote:

> On 10/30/2012 05:02 PM, Jason Merrill wrote:
>
>> template <typename CharT, typename Traits, typename Alloc>
>> class [[abi_tag ("11")]] basic_string; // ABI change from refcounting
>>
>> template <class T>
>> struct complex {
>>     ...
>>     // return type changed from C++98
>>     [[abi_tag ("11")]] constexpr T real() { return _M_real; }
>>     ...
>> };
>>
>
> We started tagging the real/imag functions in 4.8, and are planning to
> start tagging the string/list types in GCC 5 (around April).  We will then
> be able to include both old and new ABIs in libstdc++ so that old and new
> code can continue to interoperate so long as they don't try to exchange
> affected data.
>
> As John McCall pointed out in earlier discussion, incomplete types make
> this problem a lot trickier, since there's no way for the compiler to
> automatically collect tags from subobjects.  So we need to rely on users to
> tag their own types as well, if they care about new and old ABI versions of
> their code coexisting within the same image.  This would not be necessary
> for most users, only for 3rd-party library vendors that don't already
> require their users to rebuild for a new version.
>
> To help library vendors add tags where needed we have the -Wabi-tag flag
> to suggest places where a tag is used on a data member, base, or virtual
> function, but not on the enclosing class.
>
> Tags are attached to names.  I've been uncertain whether for string we
> should just not use the built-in abbreviations, but I lean toward using
> them, attaching tags to them as well, and then making tagged abbreviations
> substitution candidates.
>
>  Having a way to tag individual methods for ABI compatibility breaks is an
>> interesting idea, but I think you actually need a language extension here,
>> because simply removing the old declaration and tagging the new one isn't
>> good enough if binary compatibility requires you to actually emit a symbol
>> for the old definition.  There may be relatively few non-inline symbols in
>> the STL, but there are a fair number of explicit instantiations.  Unless
>> you're planning to fake this with some *extremely* non-ODR-compliant
>> definitions hidden inside the library.
>>
>
> We're finding that just compiling instantiations in both modes is
> sufficient for libstdc++, as any duplicates are discarded by the linker.
>
> Thoughts?  We're pretty committed to making this transition in GCC 5, but
> if people have ideas about how to do it better, I'm very interested.


How about using an inline namespace for the mangling changes? That's what
they're for, after all. Then you can use your attribute simply as a way of
guiding the warning, for users who are courageous/crazy enough to want to
deal with this for every single declaration of every single class type that
might contain a std::string (read: probably no-one), and avoid pushing the
cost of your ABI break onto other vendors.

If you *can't* do it this way, then inline namespaces appear to be useless.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/cxx-abi-dev/attachments/20141119/5d42a55a/attachment.html>