On Wed, Jul 4, 2012 at 8:14 AM, Jakub Jelinek <ja...@redhat.com> wrote:
> 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.
That would not address the issue of interoperability of a C++03 library
with a C++11 program or vice versa if they are using any of the changed
interfaces for interoperability. Passing pointers to such objects still would
work and break unnoticed.
I think that it would be best to keep C++03 and C++11 interoperable
for all classes/objects as much as possible within the v6 ABI.
I understand that std::list for example would still be conforming with
C++03 with the extra member, so we can have a v7 ABI which still
allows interoperation between the two languages within the same ABI.
Not sure about the other changes. So, what's your proposal for the
v7 ABI - drop the version manglings again and have a compatible
C++03 and C++11?
Thanks,
Richard.
