[cxx-abi-dev] Library ABI version markers

[Jason Merrill]

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.

Jason