• BSDToolchain

BSD Toolchain Project

The BSD Toolchain Project aims to replace the GPL licensed components of the FreeBSD base system toolchain with modern BSD licensed tools. It is an umbrella for a number of independent efforts working on toolchain enhancements. The main sub-projects are:

• ClangBSD - An effort to import the Clang C/C++/Objective-C compiler from the LLVM Project into the base system.

• The ELF Tool Chain Project - A project to create BSD licensed replacements for GNU binutils.

• libc++ - A new BSD licensed C++ standard library.

• libcxxrt - A new BSD implementation of the Itanium C++ ABI used by FreeBSD. This provides the low-level parts of the C++ implementation: exception handling, RTTI, and so on.

External Toolchain Support

In addition to replacing tools, we are also working to add support for external toolchains. This has been a needed feature for many years and will provide significant benefits to embedded developers who often need to run vendor provided toolchains. An explicit goal of external toolchain support is to support any compiler with a gcc compatible driver. Another goal is that using external toolchains should be easy. Developers should generally need to do no more that set a variable like BOOTSTRAP_TOOLS=/path/to/my/tools in their buildworld/buildkernel runs to use external tools. Individual tool paths and arguments should be further overridable, but uses should not need to do this if they have a sensible collection of tools in a central location.

See also ExternalToolchain.

Technical Benefits

While this project is significantly motivated by license needs, many of these tools represent a step forward technically. In most cases these tools benefit from being relatively new projects without much cruft in their code bases. For example they only support operating systems, executable formats, and architectures people actually use today.

Clang/LLVM

Clang and LLVM have a number of benefits which can be read about on their respective pages. A few key examples:

• Vastly improved warnings and error messages due to parser design.
• Compilation is fast enough to use for syntax highlighting.
• LLVM is always a cross compiler.
• Ability to JIT code.
• Blocks support.

Roadmap

As a result of the BSDCan 2010 Toolchain Summit we have created a general plan to move the toolchain forward. At the summit there was wide acknowledgment that achieving our goal of a modern BSD licensed toolchain will take significant effort and will require taking risks. There was general agreement that if we want to do this, the only realistic compiler option was clang/LLVM. As a result there is a secondary goal to our actions of sending a strong signal of our direction. This will direct efforts at the right external projects and help vendors plan their development efforts. Our goals are currently divided very coarsely into long, middle, and short term goals.

Short Term

In the short term we plan to make things easy to test and provide a strong signal of our overall intent. This means:

• Clang should be imported into HEAD to simplify testing ASAP. (2010-06-09)

• Support for bootstrapping with clang should be added after the clang import is stable..(2010-09-22)

• External toolchain support should be added(2014-11-29)

• Ongoing work on building and running ports with clang should continue.

Mid Term (9.0)

For the 9.0 release we propose that the following thing be true:

• as(1) and ld(1) to be upgraded to the last GPLv2 versions.(Rev 218822)

• gdb to be upgraded to the last GPLv2 version.

• External toolchains work easily.

• Clang builds and installs as clang/clang++ on all useful platforms (can be disabled with WITHOUT_CLANG or similar).

• Clang can be optionally installed as cc/c++ (or cc/c++ replaced with a wrapper like the sendmail one).

• Clang can be used to bootstrap some platforms with the right switch (i.e. BOOTSTRAP_WITH_CLANG).

  • If some platforms prove particularly stable we may consider making bootstraping with clang the default on those platforms.
• GCC will continue to be built and installed as cc/c++ by default.
• Most pieces of binutils will be replaced by ELF Tool Chain project equivalents.
• No new critical functionality that requires clang/llvm.
• No new functionality that is fundamentally incompatible with clang/llvm.

Long Term (10.0+)

Our long term goal is for the base system to include a modern BSD licensed toolchain without any GPL licensed componants. To make this happen we need to replace:

• gcc
• binutils (as, ld, nm, strings, etc)
• gdb
• libgcc
• libstdc++

In the long term ports are expected to grow the ability to have a ports specific compiler rather than relying on cc/c++ (though cc should be compatible with this compiler). Work under Google Summer of Code 2010 to support clang as the compiler for ports will include pieces that can be adapted to accomplish this.

It may be the case that we support some architectures which do not have a compiler in the base system. As indicated above this is critical for embedded work and will be the way forward if necessary for architectures which LLVM does not support. In many cases we can hope that will be rectified, but in others the platforms will simple be too obscure to support.

Status

Fill this in, referencing appropriate external resources as needed.

C++ Notes

The GNU C++ stack consists of several components:

• libstdc++ provides the STL implementation. Programmers call this library.
• libsupc++ provides the low-level parts of C++, such as RTTI, C++ exceptions, locks for guard variables, and so on. The compiler inserts calls to this library (it is not - usually - exposed directly to programmers)
• libgcc_s provides the generic unwind library
• g++ provides the compiler

Most of these have BSDL replacements: libstdc++ can be replaced with libc++, libsupc++ with libcxxrt, and g++ with clang. The supporting libc code is now all in CURRENT and so libc++ can be built with libcxxrt and FreeBSD libc and pass most of its test suite (more than it passes on Darwin, where it was originally written).

The main missing part is the generic unwind part provided by libgcc_s. This can be replaced by libunwind, although this will require some care, especially to avoid exporting private functions, and some testing.

ARM

ARM uses a stupid exception ABI. Unlike the Itanium ABI (used by all other FreeBSD architectures), the personality function (the language-specific unwinder) is responsible for unwinding the stack. In the GNU stack, libgcc_s provides a set of helper functions so that all the personality function has to do is call one of these. These are not present in libunwind - we'll need to implement them.

Events

Future

• LLVM Developers Meeting (TBD)

Past

• BSDCan 2010 Toolchain Summit - Summary

CategoryHistorical