This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Dealing with C++98/11 ABI incompatibilities


There seem to be two areas of concern with compatibility between the C++98 and C++11 ABIs:

1) Changes to member function return types, as with std::complex. For these, the two functions could coexist except that they are mangled the same way. So I propose that we introduce a mechanism to change the mangled name of a member function. Unlike with attribute ((alias)), the declared name would only be visible at the source level, not in the assembly output.

My inclination is to just have a single declaration and have an attribute to change its name for linkage purposes.

In the passed we have discussed using inline namespaces to do this sort of renaming, but that doesn't help with individual member functions within a class, like the situation in std::complex.

2) Object layout changes to std::list and std::basic_string. For these types, there is no way to both retain backward compatibility with older C++98 code and conform to the C++11 standard. The best we can hope for is to allow old code to coexist with new code so long as they don't try to touch the same string/list objects.

As above, one solution to this would be to change the linkage name of the new versions so that they don't clash with the old versions. But that isn't enough in this case, as it wouldn't affect the linkage name of a class like

struct Wrap { std::string s; };

so we would need some way to cause the name decoration to propagate to other containing/derived classes.

It seems that ELF symbol versioning could be useful for this purpose. If we were to extend the visibility attribute to also handle symbol versions, that could handle a lot of issues. If Wrap uses the GLIBCXX_4 version of string, then Wrap would also be marked with the GLIBCXX_4 version, and any functions that deal with Wrap would be marked with that version, and so on.

I'm not familiar enough with the intricacies of ELF versioning to be confident that this would work; is anyone else? In particular I'm not sure how the interaction of versioned and non-versioned code will work.

Jason


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]