Category Archives: Toolchain

New Device Tree Compiler

This week, I imported a new device tree compiler, dtc(1). This is the tool that is used to translate between different representations of a Flattened Device Tree (FDT), a way of representing boot-time configuration information. The FDT contains more or less the same information as an OpenFirmware device tree, for example the locations of memory-mapped peripherals, reserved sections of RAM, interrupt routing information, and so on.

FreeBSD/ARM makes a lot of use of FDTs, as they’re the standard way of getting information from the bootloader. They are used in two ways. The ideal way is for the bootloader to provide the tree to the kernel at boot time. This allows a single kernel to be used with multiple SoCs. Alternatively, the device tree can be compiled into the kernel.

The device tree in both cases is in the form of a Device Tree Blob (DTB), a binary representation of the tree. The ‘flattened’ in the name comes from the fact that the tree is represented in a linear structured format, like HTML, with explicit delimiters for starts and ends of child nodes, rather than in a format with pointers between elements. The other representation, the Device Tree Source is a human-readable tree using braces to delimit children and is rather similar to the OpenStep property list format or JSON.

The device tree compiler is responsible for converting between these formats. In the FreeBSD tree, we have a number of DTS files that represent supported platforms where the bootloader doesn’t provide the DTB. During the build process, the DTB is generated and linked into the kernel.

Unfortunately, the existing tool was released under the GPL. We try to minimise the amount of GPL’d code installed by default, and intend to remove all of it by 10.0, so dtc was not installed unless your target platform used it (a bit silly, as you want to use it on your host platform when doing embedded device development). The new tool is a (BSD-licensed) from-scratch rewrite that I did over Christmas. It shares no code with the original, but works as a drop-in replacement in our build system.

It is now used by default, although the old GPL’d tool will remain available as an option for a while until I’m confident that we aren’t breaking out-of-tree dtc users. So, if you’re using FDTs and don’t have the DTS in the tree, please test it. Otherwise, this is just another step on the way to a fully GPL-free base system.

The New C++ Stack in 9.1

If you read the release announcement, then you’ll have seen that there is a new C++ stack in 9.1, but that it is marked optional and is not part of the default binary install. If you’re a C++ developer, you may want to play with it for a few reasons:

  • It supports C++11 (which is new, shiny, and buzzwordy)
  • It will be the only one shipped by default in 10.0, so if you care about forward compatibility then you will need to test with it or make sure that your code works with it, or depend on GNU libstdc++ from ports.

The new stack uses libcxxrt, which I originally wrote for PathScale and was since open sourced (funded by the FreeBSD and NetBSD Foundations).  This implements the low-level part of the C++ standard library, providing things like support for RTTI, dynamic_cast, exceptions, thread-safe initialisation of statics, and so on. In the old stack, libsupc++ does this.

On top of this sits the STL implementation. In the old stack, this was GNU libstdc++, in the new one it’s LLVM’s libc++. To make interoperability easier, in 9.1 we have made libstdc++ dynamically link against libsupc++. You can use libmap.conf(5) to tell it to link against libcxxrt instead, and then you can mix libraries that use libc++ with ones that use libstdc++ in the same program.

The new stack isn’t installed by default, but building and installing it is very easy:

# cd /usr/src/lib/libcxxrt
# make
# make install
# cd ../libc++
# make CXX=clang++
# make install

You should now have installed in /usr/lib and the headers installed in /usr/include/c++/v1. You are now ready to compile C++ code with the new stack. You use them, clang has a command-line switch for selecting the stack to use. By default, it will still use the old stack:

$ clang++ 
$ ./a.out 
Hello C++ World
$ ldd ./a.out 
./a.out: => /usr/lib/ (0x800819000) => /lib/ (0x800b29000) => /lib/ (0x800d4a000) => /lib/ (0x80109d000)

To enable the new stack, you must add -stdlib=libc++ to your CXXFLAGS and also to your LDFLAGS. The first ensures that we get the libc++ headers, the second that we link to libc++:

$ clang++ -stdlib=libc++ -std=c++11 
$ ./a.out 
Hello C++ World
$ ldd ./a.out 
./a.out: => /usr/lib/ (0x80081a000) => /lib/ (0x800ac9000) => /lib/ (0x800cea000) => /lib/ (0x800ef7000) => /lib/ (0x80124a000)

Unfortunately, in 9.1 there is a small bug that prevents you from compiling in C++98 mode with libc++. The C11 quick_exit() and at_quick_exit() functions are exposed in our stdlib.h only in C11 and C++11 modes, but are referenced in libc++’s cstdlib in any mode.

Most code should work out-of-the-box in C++11 mode though, so there’s little reason not to try it. And, because of the availability of move semantics, some code using STL classes will be more efficient when compiled in C++11 mode.

If you want to test with a newer version, but don’t want to install -CURRENT, I’m putting x86-64 binaries of libc++ back-ported to 9.1 online for testing. I’ll update this whenever I pull a new version into -CURRENT.