LSB patch to gcc 3.3 tree

[Benjamin Kosnik]

>From the gcc-3_4-branch, I see that libstdc++-v3/config/linker-map.gnu
>exports a huge number of symbols for GLIBCXX_3.4.
>In particular, as far as LSB is concerned, it exports
>* for vtables:
>
>    _ZTVSt23__codecvt_abstract_baseI[cw]c11__mbstate_tE;
>    _ZTVSt21__ctype_abstract_baseI[cw]E;
>
>* for typeinfo structures
>
>    _ZTISt21__ctype_abstract_baseI[cw]E;
>    _ZTISt23__codecvt_abstract_baseI[cw]c11__mbstate_tE;
>
>* for typeinfo names:
>
>    _ZTSSt21__ctype_abstract_baseI[cw]E;
>    _ZTSSt23__codecvt_abstract_baseI[cw]c11__mbstate_tE;

Right. I think this is all that is actually required. 

>* regular entities
>
>    # std::__codecvt_abstract_base*
>    _ZNStSt23__codecvt_abstract_base*;
>
>So, while std::__codecvt_abstract_base* is exported, no such
>thing happens for std::__ctype_abstract_base.

... this is actually unused, and can be deleted.

So, these are the symbols that end up getting exported for 3.4.x:

OBJECT:29:_ZTSSt21__ctype_abstract_baseIcE@@GLIBCXX_3.4
OBJECT:29:_ZTSSt21__ctype_abstract_baseIwE@@GLIBCXX_3.4
OBJECT:32:_ZTISt21__ctype_abstract_baseIcE@@GLIBCXX_3.4
OBJECT:32:_ZTISt21__ctype_abstract_baseIwE@@GLIBCXX_3.4
OBJECT:32:_ZTISt23__codecvt_abstract_baseIcc11__mbstate_tE@@GLIBCXX_3.4
OBJECT:32:_ZTISt23__codecvt_abstract_baseIwc11__mbstate_tE@@GLIBCXX_3.4
OBJECT:44:_ZTVSt23__codecvt_abstract_baseIcc11__mbstate_tE@@GLIBCXX_3.4
OBJECT:44:_ZTVSt23__codecvt_abstract_baseIwc11__mbstate_tE@@GLIBCXX_3.4
OBJECT:45:_ZTSSt23__codecvt_abstract_baseIcc11__mbstate_tE@@GLIBCXX_3.4
OBJECT:45:_ZTSSt23__codecvt_abstract_baseIwc11__mbstate_tE@@GLIBCXX_3.4
OBJECT:64:_ZTVSt21__ctype_abstract_baseIcE@@GLIBCXX_3.4
OBJECT:64:_ZTVSt21__ctype_abstract_baseIwE@@GLIBCXX_3.4

This looks right to me.

>As for the support library, the exported symbols _ZN10__cxxabiv1*
>are precisely (for CXXABI_1.3):
>
>    # *_type_info classes, ctor and dtor
>    _ZN10__cxxabiv117__array_type_info*;
>    _ZN10__cxxabiv117__class_type_info*;
>    _ZN10__cxxabiv116__enum_type_info*;
>    _ZN10__cxxabiv120__function_type_info*;
>    _ZN10__cxxabiv123__fundamental_type_info*;
>    _ZN10__cxxabiv117__pbase_type_info*;
>    _ZN10__cxxabiv129__pointer_to_member_type_info*;
>    _ZN10__cxxabiv119__pointer_type_info*;
>    _ZN10__cxxabiv120__si_class_type_info*;
>    _ZN10__cxxabiv121__vmi_class_type_info*;
>
>GCC-3.3.x can line up to those symbols, but no more.
>Similarly, the _ZNK10__cxxabiv1* symbols are:
>
>    # *_type_info classes, member functions
>    _ZNK10__cxxabiv117__class_type_info*;
>    _ZNK10__cxxabiv120__function_type_info*;
>    _ZNK10__cxxabiv117__pbase_type_info*;
>    _ZNK10__cxxabiv129__pointer_to_member_type_info*;
>    _ZNK10__cxxabiv119__pointer_type_info*;
>    _ZNK10__cxxabiv120__si_class_type_info*;
>    _ZNK10__cxxabiv121__vmi_class_type_info*;
>
>GCC-3.3.x can line up to those, but no more.

Exactly.

>Finally, for _ZN9__gnu_cxx, we have only one symbol for CXXABI_1.3:
>
>    # __gnu_cxx::_verbose_terminate_handler()
>    _ZN9__gnu_cxx27__verbose_terminate_handlerEv;
>
>
>That is it.

For 3.3.x agreed. There's no way that these blanket exports are going to fly:

 > CXXABI_1.2.2 {
| >     _ZN10__cxxabiv1*;
| >     _ZNK10__cxxabiv1*;
| >     _ZN9__gnu_cxx*;
| > } CXXABI_1.2.1;

-benjamin