Summary of Sessions at the BSDCan 2010 Toolchain Summit
This page summarizes the results of the BSDCan 2010 Toolchain Summit.
In writing this summary I've attempted to balance the various view points at the summit, but may not always have succeed, if you have questions or concerns, please contact me. -- BrooksDavis
ClangBSD - RomanDivacky
Roman presented ClangBSD, a branch in the FreeBSD Subversion repository which incorporates the clang C/C++ compiler as the bootstrapping compiler replacing gcc for nearly compilation. Such a configuration was deemed too aggressive for a first step in the base system, but it represents a good demonstration of where we could be headed on the compiler side.
The current status of ClangBSD along with instructions for testing can be found on the BuildingFreeBSDWithClang page. At the time of the summit i386 and amd64 support was fairly solid and other platforms were untested.
External Toolchain Support - WarnerLosh
Warner discussed the need to support external toolchains in FreeBSD. In the embedded world there has long been a need to build OSes with nonstandard compilers, often compilers with large vendor patches to support particular architectures. FreeBSD has been deficient in this area for years. Warner proposes adding simple support where only a few variables need to be set to use an external toolchain to build the system. Additionally, there was discussion of the need for ports of gcc with the required FreeBSD extensions to handle our kernel printf modifications. Both of these would significantly ease the work of embedded developers and would allow users to build with newer compilers in the near term. Such changes could be merged to stable branches with little risk.
BSD Elf Tools Status - BrooksDavis
I presented the current status of the BSD licensed ELF Tool Chain project Joseph Koshy and Kai Wang are working on. They aim to replace the non-compiler portions of the toolchain with BSD licensed tools. Thus far we have replaced ar(1) and this summer many other tools such as nm(1) and strings(1) are scheduled to be replaced. At that point the remaining pieces will be the assembler, compiler, debugger, and linker.
BSD Debugger - DougRabson
Doug gave a presentation on his new debugger. The debugger aims to support modern processors and operating systems while. It is not yet complete, but Doug uses it himself and it has a number of cool features such as handling breakpoints properly within inlined code. The biggest downside of the new debugger is that it is written in D. Fortunately there is a D compiler frontend for LLVM so importing it is not impossible.
LLVM Brainstorming - RobertWatson
Robert lead a session brainstorming ideas for (crazy) things we could do if we had LLVM in the base. These included both things you could do optionally without modifying the source as well as more extensive modifications. Some of these ideas not captured on his slides include:
- Precompiled headers.
- JIT support for various languages.
- Dynamic hardware feature support.
- Profile driven optimization.
- Runtime code replacement.
Other ideas discussed at the conference included a machine independent BPF JIT and the idea a compiled firewall rule set. Full slides for this session can be found at 201005ToolchainSummit.
Roadmap
We ended the day with a discussion of goals, needs, and action items that together form a roadmap of sorts. The primary goal of the session was to promote a modern BSD(ish) licensed toolchain in the base system. There was wide acknowledgment that achieving this goal 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. I've divided up our plans
Long Term (10+)
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
- 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.
Mid Term (9.0)
For the 9.0 release we propose that the following thing be true:
- 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.
- as(1) and ld(1) to be upgraded to the last GPLv2 versions.
- gdb to be upgraded to the last GPLv2 version.
- External toolchains work easily.
- No new functionality that requires clang/llvm.
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.
- External toolchain support should be added.
- Support for bootstrapping with clang should be added after the clang import is stable.
- Ongoing work on building and running ports with clang should continue.