Note that this page is primarily of historical interest - the work described on this page is largely complete, and the main GPLinBase page tracks the remaining work items.

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:

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 and LLVM have a number of benefits which can be read about on their respective pages. A few key examples:


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:

Mid Term (9.0)

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

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:

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.






Clang/LLVM Import


Imported into base, builds world for i386/amd64. Targeted as bootstrap compiler for i386 and amd64 in 9.0




Many tools replaced. All classic binutils but as and ld written.




Arithmetic and similar routines replaced with compiler_rt. Still need generic unwind code.


David Chisnall

Works on -CURRENT, passing more tests than on Darwin



Owner Needed

LLDB is ported to FreeBSD. An ELF only or ELF and Mach-o debugger will mostly meet our needs. We need to make kernel crash dumps ELF format though.


Fill this in, referencing appropriate external resources as needed.

C++ Notes

The GNU C++ stack consists of several components:

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 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.




CategoryProject CategoryHistorical

BSDToolchain (last edited 2021-04-26T04:27:54+0000 by KubilayKocak)