Update libcxxrt to upstream commit 00bc29eb6513624824a6d7db2ebc768a4216a604
ClosedPublic
Actions

Authored by dim on Dec 28 2014, 11:08 PM.

Details

Reviewers

theraven
bapt

Commits

rS276417: Import libcxxrt master 00bc29eb6513624824a6d7db2ebc768a4216a604.

Summary

For PowerPC, I particularly need https://github.com/pathscale/libcxxrt/commit/76584a04feb716c2a39def6ff70b51a4806e084d which avoids using 64 bit atomic ops on it, but since that changes quite a lot of code, I thought it would be handy to do a complete import again.

This tries to preserve our own customizations, e.g. r255093 ("Don't use _Unwind_Backtrace() on ARM"), r256642 (deep typeinfo comparison), r273381 and r273382 (implementation of __cxa_throw_bad_array_new_length with temporary build fix).

I will do an import via the vendor area to actually commit this later.

Test Plan

Compile world and run it.

Diff Detail

Repository

rS FreeBSD src repository - subversion

Lint

Lint Skipped

Unit

Tests Skipped

Event Timeline

dim updated this revision to Diff 2905.Dec 28 2014, 11:08 PM

dim retitled this revision from to Update libcxxrt to upstream commit 00bc29eb6513624824a6d7db2ebc768a4216a604.

dim updated this object.

dim edited the test plan for this revision. (Show Details)

dim added reviewers: theraven, bapt.

Hm, I already found one problem with this update. It added a static_assert for the 32-bit non-ARM case, but that leads to an error:

contrib/libcxxrt/guard.cc:104:1: error: C++ requires a type specifier for all declarations
static_assert(sizeof(guard_t) == sizeof(uint64_t), "");
^~~~~~~~~~~~~
1 error generated.
*** Error code 1

Must we now compile this code with -std=c++11? That would be a little annoying. It seems that assert.h only defines static_assert for ISO_C_VISIBLE >= 2011 && !defined(cplusplus).

Otherwise, I'd opt for just deleting this static assert, or putting it in #if blocks that test for C++11 support.

Put the static_assert between ifdefs, so we are not force to compile this in C++11 mode.

dim added inline comments.Dec 29 2014, 12:19 AM

contrib/libcxxrt/stdexcept.h
84 ↗	(On Diff #2906)	Note that this changes the mangling of bad_array_new_length. Baptiste, is this possibly the "not properly defining __cxa_throw_bad_array_new_length anymore" problem you were talking about on IRC?

Andrew, maybe you can provide some feedback specifically on the ARM parts.

I can't see anything obviously wrong with the ARM case but I don't have hardware available to test on for at least another week.

dim added inline comments.Dec 29 2014, 8:15 PM

contrib/libcxxrt/stdexcept.h
84 ↗	(On Diff #2906)	Actually, this is bogus. I compared symbols in libcxxrt.so.1 before and after this update, and the symbols do not change in any way. So there should be no change for applications that were linked to earlier versions of libcxxrt.so.1.

theraven added inline comments.Dec 29 2014, 9:04 PM

contrib/libcxxrt/guard.cc
105 ↗	(On Diff #2906)	This should work if you change it to _Static_assert, which I think we support for all C/C++ versions.
contrib/libcxxrt/stdexcept.h
84 ↗	(On Diff #2906)	There will be a change in the RTTI, though the symbols are the same. Anything that tries to catch a bad_alloc exception, for example, or dynamic_cast the thrown exception to bad_alloc, would not work with the old version but will with the new.

dim added inline comments.Dec 29 2014, 9:37 PM

contrib/libcxxrt/guard.cc
105 ↗	(On Diff #2906)	Yes, that works.
contrib/libcxxrt/stdexcept.h
84 ↗	(On Diff #2906)	Hmm, don't you mean programs that were catching a bad_array_new_length exception? I'm not sure if we already released a FreeBSD version with this type in it; if not, then I suggest to just use the standards-compliant type now. Otherwise, we will probably need to supply two versions of type, in some way?