Date: Sun, 27 Jan 2013 17:52:06 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: David Chisnall <theraven@FreeBSD.org> Cc: toolchain@FreeBSD.org Subject: Re: C++ runtime version patch for testing Message-ID: <20130127155206.GN2522@kib.kiev.ua> In-Reply-To: <90749775-2C2E-4E8B-9BC2-670BE5F2798B@FreeBSD.org> References: <EDDAA896-D752-450F-89A0-4831FB016AC5@FreeBSD.org> <20130127150313.GM2522@kib.kiev.ua> <90749775-2C2E-4E8B-9BC2-670BE5F2798B@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--5NVDATmc8A1f9nDP
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sun, Jan 27, 2013 at 03:17:51PM +0000, David Chisnall wrote:
> On 27 Jan 2013, at 15:03, Konstantin Belousov wrote:
>=20
> > On Sun, Jan 27, 2013 at 01:28:44PM +0000, David Chisnall wrote:
> >> + std::set_new_handler*;
> > What are the symbols you assigning the version there ? I cannot find
> > anything in the libstdc++.so export list which would match the line.
>=20
> std::set_new_handler(void (*)())
>=20
> # objdump -T /usr/lib/libsupc++.so | c++filt | grep new_h
> 0000000000009010 __float128 DF .text 000000000000000e GLIBCXX_3.4 std=
::set_new_handler(void (*)())
Apparently c++filt from 2.23.1 binutils has bug, c++filt is
not able to demangle the set_new_handler.
>=20
> >> + std::set_terminate*;
> >> + std::set_unexpected*;
> >> + std::bad_alloc*;
> >> +
> >> + std::bad_alloc*;
> > std::bad_alloc seems to be duplicated.
>=20
> Thanks, removed.
>=20
> > Besides that, pristine libstdc++.so exports 'std::bad_alloc::what() con=
st'
> > at the GLIBCXX_3.4.9 namespace. You did this for the *::what()' from
> > libcxxrt but not for the libsupc++.
>=20
> Ooops. I wrote a script that checked for version mismatches, but for som=
e reason I missed this one. Running it again, it shows two mismatches, bot=
h fixed in the new version of the diff.
>=20
You need to add 'std::bad_typeid::what() const' to 3.4.9 as well, it
seems.
>=20
> >> + std::bad_cast*;
> >> + std::exception*;
> >> +
> >> + "typeinfo for std::bad_alloc";
> >> + "typeinfo for std::bad_cast";
> >> + "typeinfo for std::exception";
> >> +
> >> + "typeinfo name for std::bad_alloc";
> >> + "typeinfo name for std::bad_cast";
> >> + "typeinfo name for std::exception";
> >> +
> >> + "vtable for std::bad_alloc";
> >> + "vtable for std::bad_cast";
> >> + "vtable for std::exception";
> >> + };
> >> };
> >>=20
> >> CXXABI_1.3.1 {
> >> Index: lib/libcxxrt/Version.map
> >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> >> --- lib/libcxxrt/Version.map (revision 245840)
> >> +++ lib/libcxxrt/Version.map (working copy)
> >> @@ -209,18 +209,7 @@
> >>=20
> >> "std::type_info::type_info(std::type_info const&)";
> >> "std::type_info::type_info(std::type_info const&)";
> >> - "std::type_info::~type_info()";
> >> - "std::type_info::~type_info()";
> >> - "std::type_info::~type_info()";
> >> "std::type_info::operator=3D(std::type_info const&)";
> > [omitted]
> >=20
> > Do applications record the dependency on the libcxxrt directly,
> > using the DT_NEEDED tag ?
>=20
> I don't believe so, they get it indirectly via libc++ or libstdc++. How =
can I check?
>=20
Do readelf -d <some binary> and look for the needed tags. If libcxxrt
is not passed on the linker command line and not recorded as needed
in the libc++/libstdc++, it should be fine.
Your changes to libcxxrt obviously break the ABI, removing the symbols
=66rom the version namespace, but my hope is that namespace for libcxxrt
is actually not part of the _system_ ABI. Thus the question.
--5NVDATmc8A1f9nDP
Content-Type: application/pgp-signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (FreeBSD)
iQIcBAEBAgAGBQJRBU0mAAoJEJDCuSvBvK1BNUEP/irf94I6mfOmRqyRPSTCRfGI
X16/h9E8fJ2wHNhft2++lORD74SM0P+RaRSPlYP0ff4HDotrE5vZ2kWDJuXSxMye
lPlRQzWu0rvrJpZeh50SlJwltqd/Z8BD6oZq7EGWomXIrOndfqvipTAQfwWSFRIZ
dLoHHFC8gt0BkTvSfTL3VER6az6bDbiwEy2Xpy26ShSsXq9iaDaXBpsLmIdLU79P
KMmiEapnt4w8Uq+AZdgXtQQCYdP3XxN5/hw2Ptmiiulcd0pmDMdqnRoo+gtDkCSd
TmEHhHFWxCVtN6o3CzAbcFTVuKMwDLJu4psF/6BVfm1Il3qnZTRB9WuE7Lvw2/Iy
2V+tFc5tNI0vZjCkvMewA2ZCqbORyUsBEKUrlUIdwbfXndmo1ItJYE6fJDOtlDNz
q3/VkttNNxRvQwLjglYIMfLf9rJZk9Vq4KBpIxzPoXdGYE5/Epp9B3HXP34+8vVM
K5XXWJzKaTXpah7bOl00gznbfTWMVcW2JHkpHVIxj3H1gEDS7JMqGgX9qVJU8NnO
Q5raFcPh/J/mGI+FFqbmtyJzo2F/RUL1t9DZXc6o7VfitX/N6VRYxlbpzoZrjfy5
Z/ITyn+teGXqNQFxaO1RlBcyRmJiiE8GWPBmifqMH7nbmw901hNWLCKrCEKdpm9o
hddOr8g641hmBBxRVU+4
=mU1A
-----END PGP SIGNATURE-----
--5NVDATmc8A1f9nDP--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130127155206.GN2522>