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]

Re: Dealing with C++98/11 ABI incompatibilities


On Tue, Jul 03, 2012 at 05:01:29PM -0400, Jason Merrill wrote:
> On 07/03/2012 03:18 PM, Jason Merrill wrote:
> >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.
> 
> Jakub pointed out to me on IRC that there's no way to specify the
> version of an undefined symbol, which would be necessary to make

Yeah, plus it might interfere with C++ libraries using symbol versioning
for the things it has been designed for.

> this work.  So we're back to some change to the mangled name.

Yeah.  I'll repeat what I said on IRC, I'd add some attribute on classes
where the compiler would propagate either a bitmask from the attribute
(using bit or) or some version level (using max) to all classes related
to that class somehow (having class with the attribute as data member, or
pointer/reference to it, etc., recursively) and all mangled names
referencing those use some mangling extension (letter + the bitmask or
version level somehow encoded) inside of the mangled names.
We could reserve a couple of bits for libstdc++, and pick one of the bits
for C++11 ABI incompatible changes, say std::list (_List_Impl in it?) would
get the attribute, similarly std::string, etc.  Anything referring to
std::list somehow, including your wrapper example, or perhaps even
struct foo { std::list<whatever> ***ptr; }; would then be mangled
differently in C++11 and could coexist with C++03 std::list/std::string.

	Jakub


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