Clang and libc++ in FreeBSD 10

Clang Frontend
1

Hi all,

The first beta release of FreeBSD 10 is now out, so I thought I'd share a little bit about the state of the toolchain. For x86 (32-bit and 64-bit) and ARMv6 (and later), we are shipping:

- clang as the default C and C++ compiler
- libc++ as the default STL implementation
- libcxxrt as the default C++ ABI implementation

We currently still retain libgcc_s for the generic unwinder (we'd be very interested in the Apple one if it were moved into compiler-rt), and GNU binutils for the linker and some other utilities, but we are not shipping GCC or libstdc++ in the base system. Our plan is to bring in alternatives to these throughout the 10.x timeframe and remove all of the GNU code in 11.0. We have imported LLDB, but it is not yet in the default build. It probably will be in 10.1.

Our ports tree contains around 24000 third-party packages. Currently, around 320 (1.3%) of them require gcc to build, all of the rest are either built with clang or are some non-C-family language.

David

2

Why not use libunwind?

3

Mainly lack of time for anyone to work on integrating it into the system. It's been on my to-do list for about a year, but never been a sufficiently high priority. It will probably move up a bit after 10.0 is released.

Having looked at the Apple code, it seems a bit cleaner (although does need some refactoring so that the CPU and OS-dependent chunks are isolated rather than being big tangles of #ifdefs).

Whichever route we go, we'll need to reimplement some of the helper functions that various personality functions use on ARM.

David

4

Great.

Out of curiosity, do you know what the plan to replace binutils linker ?

-- Jean-Daniel

5

We're currently evaluating LLD and MCLinker. At the moment, MCLinker looks more promising. We're likely to import it (but not have it part of the default build) in a few months. The last blocker for it being a useable linker for the base system was version script support. Then it will need a lot of testing with the ports tree...

David

6

Was any performance measurement or code size done? I realize this may be a lot of flat userland code without much critical sections, but still would be interesting. Last time anyone commented on it -they said ~1% for mysql or something.. Even more interesting would be very recent gcc vs clang

7

For the linker? You can find some numbers for GNU ld vs Gold vs mclinker
in my AsiaBSDCon talk:

Joerg

8

This is awesome. Congratulations!

What about a blog post?

9

A blog post about this would be great. David, if you’re interested, please follow up with me off-list.

-Chris

10

Was any performance measurement or code size done? I realize this may be a lot of flat userland code without much critical sections, but still would be interesting. Last time anyone commented on it -they said ~1% for mysql

Last year I did some performance testing on FreeBSD, comparing various versions of gcc (4.2.1 and 4.7.1) and clang (3.1 and 3.2). These tests were mostly about performance of the compiler itself, and of the operating system. One of the first things I did was to compare the performance of the compilers themselves:

http://lists.freebsd.org/pipermail/freebsd-current/2012-September/036380.html

It showed quite clearly that the stories (mostly spread on the FreeBSD mailing lists and/or IRC channels) about clang supposedly taking much more memory and CPU than gcc were not only overblown, but it was actually the other way around, in most cases. (Of course I am sure it is possible to find code on which clang performs very horribly against gcc, but that would not be 'regular' code in any sense. :slight_smile:

The next test I did was to compile the FreeBSD kernel with gcc 4.2 and clang 3.2, and compare the run-time performance of the resulting kernel binaries:

http://lists.freebsd.org/pipermail/freebsd-current/2012-September/036618.html

This showed a slight speed advantage (~4%) for the clang-compiled kernel binary. Because this test was done on a slightly older Xeon machine, some people asked me to repeat it on a newer Core architecture machine:

http://lists.freebsd.org/pipermail/freebsd-current/2012-September/036756.html

This last test showed an even greater speed advantage (~10%) for the clang-compiled kernel.

Note these last tests were not comparing gcc 4.7 (the then-current stable version) against clang, because nobody has yet done the work to make the FreeBSD kernel compile with newer gcc versions.

I'm curious why libunwind wasn't used... ?

Somebody just needed to commit to doing the grunt-work, and it apparently did not happen. :slight_smile:

-Dimitry