Date: Sat, 26 Nov 2011 20:59:29 +0000 From: David Chisnall <theraven@FreeBSD.org> To: current@FreeBSD.org Subject: Heads up: New C++ stack Message-ID: <55EF58C0-0E9A-4701-B309-95317913A384@FreeBSD.org>
next in thread | raw e-mail | index | archive | help
Hi, I've just imported libc++[1] and libcxxrt[2] to head. libc++ is UUIC = licensed, libcxxrt is 2-clause BSDL. The former implements the C++ = standard template library, and provides all of the programmer-visible = parts. The latter provides an implementation of the ARM and Itanium ABI = specifications providing the dynamic parts of the language (RTTI, = exceptions, and so on). This combination working out-of-tree and passing almost all of the test = suite (the failing parts are related to missing C1x functionality in = libc and missing C++11 / C1x atomic intrinsics in clang). =20 The goal of this is to have a working, permissively licensed, C++11 = stack. libc++abi would be an alternative to libcxxrt, but I would = prefer to use libcxxrt because: - I am totally biased towards libcxxrt because I wrote it. - libcxxrt is already shipping in PathScale's C++ stack and has been = fairly well tested. - The demangler in libc++abi is bigger than the whole of libcxxrt and = allocates a lot of memory in code that is called to generate helpful = errors for out-of-memory conditions. - libc++abi seems to be completely missing the exception personality = function. This was the hardest thing to get right in libcxxrt = (debugging code that destroys the stack as it runs is not fun), so at = this point it's basically uninteresting - more code, less functionality. libcxxrt and libc++ are now in contrib and building with the base = system, but are not used by anything (and are only built if you set = WITH_LIBCPLUSPLUS=3Dyes when building world, not by default). If you = want to test some code with the new stack, you need to build it and then = specify -stdlib=3Dlibc++ to clang++ (both when compiling and linking). I'd like to see if we can persuade libstdc++ to link against libcxxrt = instead of libsupc++ (In theory this should be easy, but I've never = tried it. Apple ships both linked against libsupc++). This means that = code can link against libraries that use libc++ and libstdc++ without = things like exceptions breaking. =20 Eventually (FreeBSD 10 timeframe), I'd like to see the libstdc++ = currently in base moved into a port so that we can ship a GNU-free C++ = stack. Any complaints / comments / contradictions / opinions? David P.S. libcxxrt does support the weird GNU variant of the weird ARM = variant of the C++ ABI, but I only finished that support very recently = and it's not nearly as well tested as the ABI used on... everything = else. It also only supports DWARF 'zero-cost' unwinding, not setjmp / = longjmp unwinding, so it can't be used until we finish moveing ARM to = EABI. =20 [1] http://libcxx.llvm.org/ [2] https://github.com/pathscale/libcxxrt=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?55EF58C0-0E9A-4701-B309-95317913A384>