Page MenuHomeFreeBSD

Add __cxa_deleted_virtual to libcxxrt's version map
ClosedPublic

Authored by dim on Jun 17 2015, 6:58 PM.

Details

Summary

See https://bugs.freebsd.org/200863 for details. The patch there adds
it to the first part of libcxxrt's version map, under CXXABI_1.3, but
when I checked upstream libsupc++, they put this symbol under
CXXABI_1.3.6. So we should probably also put it under this version.

That said, I'm not entirely sure about the dependencies, e.g. whether
CXXABI_1.3.6 shoudl be depending on CXXABI_1.3.1 or something else.

Alternatively, we could put these under the CXXRT_1.0 part, since some
of the functions there (e.g cxa_allocate_dependent_exception and
cxa_free_dependent_exception) are in CXXABI_1.3.6 in libsupc++. So we
are not compatible with libsupc++ on that front anyway.

Diff Detail

Repository
rS FreeBSD src repository
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

dim retitled this revision from to Add __cxa_deleted_virtual to libcxxrt's version map.Jun 17 2015, 6:58 PM
dim updated this object.
dim edited the test plan for this revision. (Show Details)
dim added reviewers: emaste, theraven.
dim updated this revision to Diff 6272.
emaste added inline comments.Jun 17 2015, 7:01 PM
lib/libcxxrt/Version.map
293 ↗(On Diff #6272)

should this be 1.3.6 now

dim added inline comments.Jun 17 2015, 7:08 PM
lib/libcxxrt/Version.map
293 ↗(On Diff #6272)

Yes, that is very likely.

dim updated this revision to Diff 6273.Jun 17 2015, 7:09 PM

Make CXXRT_1.0 dependent on CXXABI_1.3.6 instead.

emaste edited edge metadata.Jun 17 2015, 7:28 PM
emaste accepted this revision.

I think this is fine, but would like to have @theraven comment as he can probably provide a definitive answer.

This revision is now accepted and ready to land.Jun 17 2015, 7:28 PM
theraven edited edge metadata.Jun 18 2015, 8:38 AM

Phabricator doesn't seem to want to show me the diff, but it sounds sensible. Have we shipped a version in 9/10 that uses this symbol? If so then we should check that old binaries still run with the new .so, otherwise I think it's fine.

Generally, I'd been following the policy that symbols that were not present in libsupc++ in 8.x go in the CXXRT version namespace to avoid conflicts, but I don't see a problem with putting them in the other namespace as well. I think (hope?) that libstdc++ in ports is linking libcxxrt instead of libsupc++, so it shouldn't matter what we're doing, as long as we're self-consistent.

dim added a comment.Jun 19 2015, 9:34 PM

Phabricator doesn't seem to want to show me the diff, but it sounds sensible. Have we shipped a version in 9/10 that uses this symbol?

It depends on what you mean with "uses". The function itself was introduced in r253159, when 10.x was still -CURRENT, and merged to 9.x in r253222. But the function was never in Version.map earlier, so it was not exposed.

If so then we should check that old binaries still run with the new .so, otherwise I think it's fine.

Bug 200863 was specifically about 10-stable, where it caused "undefined reference to `__cxa_deleted_virtual'". So I think we can safely assume nothing will break by adding it. :-)

Generally, I'd been following the policy that symbols that were not present in libsupc++ in 8.x go in the CXXRT version namespace to avoid conflicts, but I don't see a problem with putting them in the other namespace as well. I think (hope?) that libstdc++ in ports is linking libcxxrt instead of libsupc++, so it shouldn't matter what we're doing, as long as we're self-consistent.

Ports gcc uses the same approach as a hand-built gcc, it dumps the libsupc++ object files directly into libstdc++.so:

$ readelf -aW /usr/local/lib/gcc49/libstdc++.so.6 | grep cxa_deleted
  2402: 0004c1c0    36 FUNC    GLOBAL DEFAULT   11 __cxa_deleted_virtual@@CXXABI_1.3.6
  3531: 0004c1c0    36 FUNC    GLOBAL DEFAULT   11 __cxa_deleted_virtual
This revision was automatically updated to reflect the committed changes.