On Sun, Mar 20, 2011 at 01:58:24AM +0100, Benjamin Kosnik wrote: > 2011-03-19 Jakub Jelinek <ja...@redhat.com> > > * config/abi/pre/gnu.ver (CXXABI_1.3): Don't export _ZT[IS][PK]*[no]. > (CXXABI_1.3.5): Export _ZTI[PK]*[no]. > > This looks good to me, nice catch. I'll figure out what happened with > check_abi when I'm back, conductivity-wise.
For _ZTSn etc. I think this shouldn't be a problem, as from what I can see _ZTI* for builtin types lives just in libstdc++/libsupc++ and thus it should be sufficient to export _ZTI* (unless somebody links -lsupc++ or libstdc++.a into dynamically linked code, but that would be user error). > And: > > > And another question is, we still export a bunch of new _ZTS* symbols, isn't > > that now pointless when we always do strcmp anyway? > > Yes, indeed it is as long as !__GXX_TYPEINFO_EQUALITY_INLINE && > !__GXX_MERGED_TYPEINFO_NAMES for all targets that have baseline > symbols. I think that is correct, since they are all linux targets. > But arm-linux too? Most of the linux targets are actually __GXX_TYPEINFO_EQUALITY_INLINE 1 and thus perhaps if we want to maintain some ABI compatibility with 3.4-ish inlined typeid comparisons, we might need to export _ZTS* for _ZTI* that could somehow be emitted for user code too. Thus perhaps the _ZT[IS][PK]*[no] change is right, but we can only do it only for the builtin types (and, clearly we've been doing that in the past, for decltype(nullptr)/_Decimal{32,64,128}/char{16,32}_t. If/when we decide to break ABI for C++, we could just make all _ZTS* symbols hidden. Jakub