[cxx-abi-dev] Library ABI version markers

[Doug Gregor]

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

:)

  - Doug