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

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.

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.

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.

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 http://www.digitalmars.com/d/ D. Fortunately there is a D compiler frontend for LLVM so importing it is not impossible.

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.

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.