[cxx-abi-dev] Library ABI version markers

[John McCall]

On Oct 26, 2012, at 3:33 PM, Doug Gregor wrote:
> On Fri, Oct 26, 2012 at 3:06 PM, John McCall <rjmccall at apple.com> wrote:
>> On Oct 26, 2012, at 2:38 PM, Jason Merrill wrote:
>>> The C++11 standard requires some ABI changes to libstdc++.  To avoid breaking the world, we want to handle this by mangling changes, limited to only those symbols that are affected by the ABI changes.
>>> 
>>> inline namespaces were intended to be a solution to this issue, but they don't really handle it very well; there's no way to adjust the mangling of a single member function (as needed for some member functions that change their return type in C++11) and they don't handle the issue of subobjects; if my type A changes ABI so I put it in an inline namespace, changing its mangling, then signatures that use it are updated appropriately.  But if type B has a member of type A, signatures that use B are not affected, leading to silent ABI incompatibilities.
>>> 
>>> From our discussions of how to deal with this we settled on an attribute which can be attached to a class or a function to affect the mangling.  I'm inclined to make the arguments to the attribute user-provided strings which will then be gathered together and attached to any symbol name that uses the class, or to the mangled name of the function, respectively.
>>> 
>>> I'm currently leaning toward collecting all the tags involved, sorting, and appending them to the symbol as <source-name>s separated by 'B's.
>> 
>> Including tags from subobjects breaks in the presence of incomplete types.  It would also make it almost completely impossible to have a binary-stable C++ API.  I think this is a non-starter, unfortunately.
>> 
>> 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.
> 
> Perhaps you mean the link_name attribute proposed here?
> 
>  http://gcc.gnu.org/ml/gcc-patches/2003-07/msg01915.html
> 
> :)

Okay, that is a *much* better idea than the language extensions I had in my head about this, about which the less said the better.

John.