more on the --enable-new-gxx-abi problems.

[Benjamin Kosnik <bkoz at redhat dot com>]

(this is a re-send of private email on Monday.)

Mark.

It appears as if different templates are being instantiated with this
switch. I've built two toolchains from the same source (today's) and
the symbols in the string-inst.o file are definitely different. It
also looks like the mangling code is kinda sketchy.....

This surprises me.

The non-new-abi (control)
%nm -A --demangle string-inst.o | grep __normal_iterator |grep U

The new-abi (test)
%nm -A --demangle string-inst.o | grep __normal_iterator |grep U
string-inst.o:         U _ZNSsC1ISt17__normal_iteratorIPcSsEEEvT_S3_RKSaIcE

(for some reason nm cannot demangle these symbols directly, with the
--demangle flag...)

%c++filt -n --format=gnu-new-abi _ZNSsC1ISt17__normal_iteratorIPcSsEEEvT_S3_RKSaIcE

void std::string::string<std::__normal_iterator<char*, std::string> >(std::__normal_iterator<char*, std::string>, std::__normal_iterator<char*, std::string>, const std::allocator<char>&)

The void return type is perhaps throwing me....

In anycase: libstdc++-v3/src/string-inst.cc (79):

  template 
    S::basic_string(C*, C*, const allocator<C>&);

  template 
    S::basic_string(S::iterator, S::iterator, const allocator<C>&);

has an explicit instantiation for this. Interestingly, neither shows
up as instantiated, but the last comes up undefined, whereas the first
is just gone..... ????

%nm string-inst.o | c++filt -n --format=gnu-new-abi > list.out



FYI: It also looks like the compression algo's are getting confused:

00000000 W void std::_S_string_copy<char, std::char_traits<char>, std::allocator<char> >(const std::basic_string<char, std::char_traits<char>, std::allocator<char> >&, std::allocator<char>*, char::size_type)

Where I'm assuming basic_string<char...> == string.



-benjamin