Submitted by Clang can build a kernel now. “The kernel can successfully boot to runlevel 5 (aka X + networking) on the Macbook, both on bare metal and in Qemu. The kernel can successfully boot to runlevel 3 on a secondary test machine, a microATX desktop box (Intel Atom). I haven’t tried to start X on this box yet. The kernel can self-host; I am currently running a ‘fourth generation’ self-hosted Linux kernel built by a ‘fourth generation’ Clang.”
Given that Linux fans generally weasel out of criticism by pointing out that the criticism aimed usually at highlevel components of a Linux system don’t apply to “Linux” (which is the kernel), I’m feeling obliged to point out that Clang “can build a kernel” for quite some time now. http://en.wikipedia.org/wiki/Clang states:
2009-02-25 for the FreeBSD kernel.
2009-03-16 for the DragonflyBSD kernel.
2010-02-20 for HelenOS.
It can successfully build Linux now, to adopt the Linux terminology.
By the way, there are some extra characters in the URL
Huh, headline fixed. Weird how the “Linux” bit dropped out of it.
The post notes that neither VDSO or the boot code build correctly with clang. The poster modified the build system to compile these two vital components with GCC. So no, clang can’t quite build a working Linux kernel on its own yet.
Aside from this, I find it a bit surprising how dependent on GCC the Linux kernel is. I do not think it behooves an open-source operating system to be so compiler-specific. Open source is supposed to be about choice, right? (Among other things)
You haven’t read the full thread, have you? On a reply [1], the same author says those things, and other that were failing, can be compiled now.
[1] http://lists.cs.uiuc.edu/pipermail/cfe-dev/2010-October/011744.html
Edited 2010-10-26 21:35 UTC
http://lists.cs.uiuc.edu/pipermail/cfe-dev/2010-October/011744.html
“VDSO compiles with Clang.”
“The boot subsystem can be built with Clang.”
What else would Linus have used in the late 80’s early 90’s? Naturally, they grew up together.
Edited 2010-10-27 02:35 UTC
Fair enough. But ‘the late 80’s and early 90’s’ was 20 years ago, now (I know, it’s shocking to me too). That is a lot of time to grow beyond meager beginnings.
Furthermore, the Linux kernel prides itself on portability almost as much as NetBSD (which is eclipsed in actual portability by Linux). Given that there are other free C compilers out there (icc, pcc, etc), you would think that Linux would have parted would GCC dependency a long time ago. Compiler dependent code strikes me as just as poor form as architecture dependent code.
The portability of Linux is pretty much described as thus: “Any system that you can port gcc to … “
It has been stated by a few kernel devs (I think Linus, but I cant find a reference), that while it may be possible, it is extremely difficult to do low level kernel development in C without leaning on some non-standard functionality in the compiler. Meaning that it they wanted to support multiple compilers they would have to conditionalize the living hell out of the headers/build system OR make the other compilers behave the same way as GCC. The later is much easier in the long haul (and is essentially what Clang is trying to do for the most part).
Try to code a kernel and you’ll find out why it’s hard not to become compiler-specific in some way.
ASM, packed attributes… No standard exists for these currently.
Until recently there was no choice. Before, GCC was the only open source compile worth using (for this purpose). There used to be a ton of good commercial compilers, but most of them have been supplanted by GCC, and it wouldn’t be reasonable to expect them to be supported.
http://clang.llvm.org/index.html
What is LLVM? Why does it exist? What technology can it be compared to? What benefit does this have to the linux kernel?
Okay I started this post as an idiot. But I would like to know what this LLVM business is.
LLVM is part of a compiler infrastructure which works like that
front-end (llvm-gcc, dragonegg, clang) –> Intermediate form (LLVM optimize this) –> Assembly code (x86, arm ..)
LLVM was started as a university research project, Apple then funded this because the switch from GPLv2 to GPLv3 in the gcc project.
The main benefits of llvm for now is the very fast compilation speed (15min for the kernel) and the error reporting which is excellent.
It had less to do with the move from GPL2 to GPL3, it had to do with Apple wanting heavier integration between the compiler and the IDE so that they could provide the sort of debugging that one see’s in the likes of Visual Studio. That sort of debugging needs heavy integration between the two and unfortunately it would be a violation of the GPL licence to which GCC is licenced under if Apple linked their proprietary application to GCC.
There are a load of other benefits that have been mentioned in previous conferences they’ve held – so it is more than just a matter of simply a response to GCC moving from GPL2 to GPL3. On a side note, there has always been a matter of friction between GCC maintainers and Apple in regards to how changes were merged back in. Now that Apple controls the development of LLVM it means it gives them more freedom or when and how they merge changes.
LLVM is a low level virtual machine (hence the name), it is in the simplest form a compiler back-end. This means that it takes code that is parsed from a language (C, C++, whatever) and converts it to a program the computer can read (or an interpreter for that matter).
Clang is the front-end for the c, c++ and objective-c/c++ languages. The combination of LLVM and Clang is equivalent to GCC with the various front-ends for the languages stated above.
Why it exists? Why does anything exist? philosophy aside, basically LLVM is supposed to be more modular than GCC, and LLVM is licensed under the BSD, while GCC is GLP.
The reason that this is interesting is because the Linux kernel has been written with the GCC compiler from the start. Being able to compile, not to mention have the code run somewhat correctly, is a milestone because software like kernels ask a lot out of compilers. Also different compilers may be able to point out problems that were not seen before.
The last thing is that because both compilers conform to an ansi spec, making sure that the kernel builds with both compilers gives better assurance that the kernel code complies with the ansi standard, which cannot hurt.
This is a great starting point
http://llvm.org/
I really want to have a go at creating my own little language for the hang of it, but time does not permit right now. Basically I could write a compiler for a new language that could be built on any number of platforms.
Nice…
Clang is an example of an app build using LLVM…
There’s an awesome little example of this here:
http://llvm.org/docs/tutorial/
It can be compared to a JVM for C. Just like Java code runs on any platform with a JVM, C/C++ code can be compiled (with clang or others) into LLVM bytecode that can be run on any platform.
IMHO that’s a major milestone. The next step would be a few distributors to switch to clang. This would make gcc and clang compete. Competition is IMHO vital for improvement.
Even if I have used neither clang nor llvm yet. But I have read about it, its concepts, its rationale. In my opinion the rationale behind llvm is sound, very sound.
Waiting for a project, in which I can use it
pica
I agree with you. I wish openwatcom and open64 were at the same level. More competition is much better. But anyway, I would also like a distro based on llvm.
How about most major BSDs (including OSX) switching to it ?
How about resurrect PureDarwin and build it and debug (lldb) it with llvm/clang.
But Linux is more popular — I do neither write nor mean better — than *BSD or Darwin.
pica
On the desktop, this is debatable. On the server, I can’t tell since I don’t know the market, but I’ve seen both debian and freebsd on university servers in my short student life.
Edited 2010-10-27 19:27 UTC
clang and llvm have been imported into the FreeBSD source tree, and it will be available as part of FreeBSD 9.0. It can build the entire FreeBSD OS (kernel, libs, boot loader, userland, toolchain), and can rebuild it all using the resulting system (ie, self-hosting). You can even build/run a FreeBSD system without GCC installed at all.
It’s not currently possible to replace GCC for building apps via the ports tree. There are quite a few apps that fail if CC != cc (gcc). But, as these are reported, fixes are sent upstream, and (hopefully) things get better in the long-run. For those that don’t build with clang, a version of GCC can be automatically installed via the ports tree, and that can be used to build the app.
Long-term, it’s very likely that GCC will disappear from the FreeBSD base install and source tree.
I agree, as long as it means that both compilers are supported. I don’t want to be trapped in some ideologic choice of compiler, I want to be able to use the best compiler for my particular needs, which can differ from project to project aswell as different project stages. Clang IS aimed to be a drop-in replacement for GCC, so when it’s compability matures we will be able to choose which compiler to use based upon what they offer technically, not because one is licenced under X and someone made a decision based upon ideology regarding which one to support, or because one compiler fails to compile certain code due to incompability.