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 refcountingtemplate <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 _______________________________________________ cxx-abi-dev mailing list [email protected] http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev
