[cfe-dev] [libc++] Running tests from cmake?

[David Chisnall]

On 21 Sep 2011, at 21:30, Marshall Clow wrote:

> On Sep 21, 2011, at 12:32 PM, David Chisnall wrote:
> 
>> Thanks to many helpful off-list emails from Howard and others, I now have a working port of libc++, running on top of libcxxrt on FreeBSD, giving us (I think) a completely GNU-free C++ stack.  For the moment, we actually have more tests passing on FreeBSD than Darwin, although I'm sure that won't last for long.  
>> 
>> Many thanks to everyone who helped make this possible,
> 
> Congratulations!
> 
> Is there a write-up of what you've done somewhere (or is this planned)?

There isn't, aside from a blog entry that the FreeBSD Foundation will be publishing soon, but I'm happy to answer any questions or write something up if you want some more details.  The FreeBSD patch is still pending code review, but you can get it here:

http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20110921/ef9d8701/xlocale-0001.obj

The changes to libc++ and libcxxrt are committed already.  

The main changes to FreeBSD involved implementing the xlocale APIs.  These are Apple extensions to the POSIX2008 per-thread locale APIs which provide _l suffixed versions of all of the locale-aware C functions that take an explicit locale as an argument.  libc++ uses these extensively[1] for the locale support.  The remaining changes were mostly fixing things where FreeBSD hid C99 declarations in C++ mode (these are mostly now visible in C++11 mode).  I also needed to fix a few bugs in FreeBSD libc.  For example, one of Howard's tests showed me that wcstod() and wcstold() returned the wrong value for strings with leading spaces.

In libcxxrt, we've now got a small set of functions for supporting exception_ptr.  These are more or less the same as the ones proposed by Sebastian Redl as extensions to the CodeSourcery Itanium C++ ABI.  The libc++ exception_ptr tests, in conjunction with valgrind, were very helpful in debugging this.  

There's a small amount of overlap between libc++ and libcxxrt (e.g. std::set_unexpected() and friends), so I added some conditional compilation to prevent libc++ from compiling these if you're compiling it for use with libcxxrt.  These might be better off as weak symbols in libc++ so that they're simply ignored if you link against libcxxrt.  Apple's libcxxabi places the layers in slightly different places.  

There wasn't much needed in libc++ beyond a little tweaking and some test fixes (some of the tests were checking implementation details of Darwin, and a few were testing the wrong thing.  For example, a few were comparing C++ strings containing NULL characters against ones constructed from C string literals - I fixed some of these, Howard fixed the rest).  A few of the code paths in libc++ hadn't been tested.  For example, converting a double to a string was done by calling asprintf... without passing the double as an argument.  There's still a code path in locale.cpp that's broken on non-Darwin, non-FreeBSD libc implementations (I added a FIXME, but I haven't fixed it).  Most of my changes were in r140245, which is a pretty small commit.  The 'port' was more a case of implementing the features that libc++ wanted, rather than modifying libc++ to work with the existing features.  

I'm currently testing libc++ for STL, libcxxrt for the ABI layer, and libgcc_s for the generic unwind code.  Roman Divacky and others at PathScale have built a replacement for this using libunwind and compiler-rt.  This is working with PathScale's C++ stack, based on Apache libstdcxx, so I don't expect any problems dropping it into this stack - but that's for Roman to do when my FreeBSD changes are committed.  So, we have all of the pieces for a completely open C++ stack and GNU ld is, I think, the last big stumbling block for a GPL-free FreeBSD 10.

David

[1] It also seems to call newlocale a lot more than it needs to - a call to std::locale() calls newlocale() 8 times, when it should only need to call it once and maybe duplocale() (which is a lot cheaper) a few times.  

P.S. I hope you'll excuse the slightly rambling structure of this mail.