Page MenuHomeFreeBSD

Update libcxxrt to upstream commit 00bc29eb6513624824a6d7db2ebc768a4216a604
ClosedPublic

Authored by dim on Dec 28 2014, 11:08 PM.
Tags
None
Referenced Files
Unknown Object (File)
Sun, Mar 10, 12:58 PM
Unknown Object (File)
Sun, Mar 10, 12:53 PM
Unknown Object (File)
Sun, Mar 10, 12:53 PM
Unknown Object (File)
Sun, Mar 10, 12:53 PM
Unknown Object (File)
Thu, Mar 7, 7:44 PM
Unknown Object (File)
Feb 22 2024, 7:07 PM
Unknown Object (File)
Jan 3 2024, 12:03 PM
Unknown Object (File)
Jan 3 2024, 12:01 PM
Subscribers

Details

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
No Lint Coverage
Unit
No Test Coverage

Event Timeline

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.

contrib/libcxxrt/stdexcept.h
84

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.

contrib/libcxxrt/stdexcept.h
84

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.

contrib/libcxxrt/guard.cc
125

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

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.

contrib/libcxxrt/guard.cc
125

Yes, that works.

contrib/libcxxrt/stdexcept.h
84

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?

bapt edited edge metadata.
This revision is now accepted and ready to land.Dec 30 2014, 6:40 PM
dim updated this revision to Diff 2925.

Closed by commit rS276417 (authored by @dim).