Re: GCC Cauldron: Notes from the C++ ABI BOF

[Ian Lance Taylor <iant at google dot com>]

My version of Cary's notes (I just wrote this on my Google+ stream):

We had a useful discussion about C++11 ABI issues at the GNU Tools
Cauldron (http://gcc.gnu.org/wiki/cauldron2012).  The approach will be
shaped over time, but the general idea is as follows.

We will modify g++ to support a type attribute indicating the version
of the type, as a string.  This type attribute will be inherited by
any other type that uses it, as a class/struct member or via
inheritance.  Type attributes will be concatenated as needed.  This
type attribute will then be used in the mangled name of any function
that takes a parameter of a type with an attribute or returns a type
with an attribute.  The type attribute will also be used in the
mangled name of any global variable whose type has an attribute.

When this feature is implemented in the compiler, we will be able to
change libstdc++ to add attributes to types.  In particular, this will
permit us to define a new version of std::string with an attribute.
Then you will get either the old version of std::string or the new
version depending on compiler options or -D options or something.
Code that uses the new version of std::string will have mangled names
that are different from the code that uses the old version of
std::string.  It's important to note that these mangled names will be
different for uses of the type that are not normally mangled, such as
function return types and global variable names.

The difference in mangled names means that code compiled using the new
std::string will not be able to call code using the old std::string,
thus ensuring that such code can not silently fail.  This will also
mean that it is possible for the same executable process to include
code that uses the old std::string and the new std::string, a
situation that can arise naturally when a C++ executable dlopens a C++
plugin.

This all matters because C++11 mandates a different definition for
std::string than the one currently in libstdc++.  This approach will
make it possible for C++11 and C++98 code to co-exist in the same
executable image.  Attempts to link them together in ways that can not
work will be rejected at link time or (by the dynamic linker) at
runtime.  This will permit us to keep the same soname for libstdc++,
simplifying life for C++ users.

We also plan to have a mode in which the compiler emits exact
information for all types, functions, and variables in a text file, in
such a way that different text files can be merged together.  We can
then use this to specify the exact libstdc++ ABI, and detect any
changes to that ABI.  This will again detect changes that are not
currently detected by looking only at mangled names and only at
instantiated templates.

This won't be particularly easy to implement, and doubtless various
issues will arise, but I think this will make it possible to
transition libstdc++ to c++11 with relatively minimal disruption for
users, and, most importantly, without any of the silent failures that
were possible in the last libstdc++ transition.

Ian