This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: LSB patch to gcc 3.3 tree
- From: Benjamin Kosnik <bkoz at redhat dot com>
- To: gdr at acm dot org
- Cc: matz at suse dot de, dbb at beatties dot us, gcc-patches at gcc dot gnu dot org, mats dot d dot wichmann at intel dot com, anderson at freestandards dot org, dbb at freestandards dot org, libstdc++ at gcc dot gnu dot org
- Date: Tue, 29 Jun 2004 00:35:34 -0500
- Subject: Re: LSB patch to gcc 3.3 tree
- Organization: Red Hat / Chicago
- References: <20040628205604.GF14453@beatties.us><32889.::ffff:128.194.146.36.1088456910.squirrel@webmail.nerim.net><Pine.LNX.4.58.0406290051440.14966@wotan.suse.de><37195.::ffff:24.250.169.187.1088469697.squirrel@webmail.nerim.net>
>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