News: Stay up to date

The Étoilé community is an active group of developers, designers, testers and users. New work is being done every day. Visit often to find out what we've been up to.


GNUstep and Clang

Posted on 31 March 2009 by David Chisnall

I'm going to break from tradition slightly now and talk a bit about something that is not directly part of Étoilé. For a while, I've been intermittently hacking on clang, the new C/C++/Objective-C front end for the LLVM compiler infrastructure. If you've done any development for the iPhone or for recent versions of OS X, you will probably have used llvm-gcc, which uses the same back end but a front end based on GCC.

Since GCC switched to GPLv3, Apple has been slowly migrating away from it. The GPL wasn't great for Apple anyway, since they wanted to be able to use the same front end code in XCode for syntax highlighting, autocompletion, and error reporting as they use in the compiler, and the GPL didn't allow them to do this without releasing XCode under a GPL-compatible license. A couple of years ago, they started the clang project to replace the GPL'd front end and create a reusable set of libraries that handled parsing, analysis, and LLVM bitcode generation for C-family languages.

Why is this relevant to Étoilé? For some very simple reasons:

  • Apple are no longer contributing much to the main GCC tree.
  • No one outside Apple contributes much to Objective-C in GCC.
  • Étoilé needs an Objective-C compiler.

The original Objective-C code in GCC was contributed by NeXT (after being attacked by the FSF's lawyers) and only supported the (closed) NeXT Objective-C runtime library. Over time, the NeXT and GNU runtimes have diverged a lot. NeXT, and later Apple, maintained their own branch of GCC and never merged support for the GNU runtime. The GNU branch maintained support for both, via an unreadable mess of #ifdefs in a single 10,000-line file.

Clang, starting from scratch, has a clean abstraction layer between the runtime-specific and runtime-agnostic bits of code. Each runtime library needs to implement a subclass of the CGObjCRuntime C++ class, which implements hooks for generating runtime library data structures and calls.

I started working on the GNU runtime support a little while ago, and it is now in a usable state. For a little while, the things that have stopped GNUstep compiling with clang have been missing support for GCC extensions to C. Now, these have all been fixed. GNUstep-base now compiles with clang, but doesn't link. The remaining issue is that LLVM does not support the __builtin_apply() family of GCC extensions. These are not actually used by GNUstep in most cases - their functionality is replaced by either libffi or libffcall - but they are still called by a few unused methods. A small restructuring of the GNUstep-base code will allow it to be compiled with the current svn version of clang. I've also tried compiling a few Étoilé frameworks with clang, and so far they've all successfully built (although I haven't tested if they work yet...).

That's not to say that clang is completely ready to replace GCC as the compiler for GNUstep and Étoilé. In summary:

  • All of the NeXT-era Objective-C stuff is supported.
  • Fast enumeration works (and is implemented for some of the GNUstep collection classes).
  • @try/@catch and so on do not work yet (although the old-style exception macros do).
  • A very small subset of declared properties may work (untested).
  • Garbage collection does not yet work.
  • Lots more testing needs to be done.

If you want to get involved, take a look at the CGObjCGNU.cpp file in lib/CodeGen in the clang repository. It contains a number of empty methods, which need implementing to bring the GNU runtime implementation up to feature-parity with the Apple version. Alternatively, try compiling your Objective-C code with the latest clang and report any errors to me and to the clang team.

Exception handling is probably the next thing to implement. The code in CGObjCMac.cpp contains a lot of things that probably should be factored out into runtime-agnostic code, so if you're interested in working on this, take a look in that file for inspiration.