
Clang (LLVM C compiler) builds a working Linux kernel - zdw
http://article.gmane.org/gmane.comp.compilers.clang.devel/11432
======
jacquesm
That's quite the milestone to achieve. I'm actually really happy to see this
happen in light of the negative rap C seems to be getting just about
everywhere.

C is far from dead, it may have its warts but it is still very much in use in
all kinds of places and a solid knowledge of C has never hurt anybody (as far
as I know).

Being able to compile the linux kernel and to get it to boot is a non-trivial
exercise in GCC compatibility, I'm very impressed with this.

I wonder if there ever will be an official 'blessing' by the kernel devs of
the LLVM C compiler.

~~~
igravious
I don't see why not in the long run if the devs bend over backward to maintain
GCC compatibility on x86. It is never a great idea to have a single point of
failure even if that point is the wonderful and awe-inspiring GCC. It is
amazing to think that nearly 20 years after conception Linux maybe be built
with an alternate tool chain. This is an incredible feat that has far-reaching
consequences for the health of the ecosystem. Maybe Linus wasn't keen on the
idea but if some people step up and bake in the support it'll be de facto
blessed.

Slightly off-topic, does anyone know if the Gold linker works with Clang?

~~~
wash
Gold should work.

ICC has been able to compile Linux for awhile, I think.

------
Rusky
The Linux kernel is explicitly built using GNU extensions, which means that in
addition to implementing the C standard, they have to deal with kernel-
specific issues as well as whatever ideas GCC has. Clang as a work-alike for
GCC will be/is incredibly useful and an incredible accomplishment.

While being able to compile Linux is definitely helpful and a good sign of
compiler maturity, the kernel developers target GCC and I'm not sure that will
ever change. This (and similar projects) will probably somewhat limit Clang
adoption as people will always need to keep GCC around rather than relying on
the portability of using standards. :(

Hopefully the competition Clang brings to the table will push at least some
open source projects to be a little less reliant on GNU.

~~~
rwl
What's wrong with relying on GNU? It's Free software that will love on as long
as the concept does. You can be assured that GNU will never have the rug
pulled out from under it by a corporate affiliate, anyway.

~~~
Rusky
Nothing's wrong with GNU; the problem is when it becomes a de-facto standard.
Having more than one compiler available will improve both as they compete, and
it keeps code more time-proof and gives developers and users more options.

~~~
rwl
A lot of people have been making this claim in this thread, but I'm a little
bit skeptical. For one thing, I'm skeptical of the idea that competition
always improves products in a commercial setting (though it surely does under
_some_ circumstances). But more importantly, I think there is a significant
disanalogy between Free software projects and businesses that sell products.
Businesses compete for customer dollars. What are Free software projects
competing for? Users? Credibility? I'm not sure. But it certainly doesn't seem
like they have the same incentives in place. People write code for FS projects
because they're interested in it, because they need the functionality, etc. --
it's something they would do even if their efforts don't attract a lot of
"customers."

What FS projects _do_ compete for is the time and interest of talented
programmers. For that reason, having competing projects can be more harmful to
them than good, because it divides the pool of programmers: more programmer
time is spent achieving common goals (like having an excellent C compiler)
than would be spent if the different groups pooled their efforts.

(This is not, of course, an argument that competing FS projects are always a
bad thing. Obviously, competing projects, forks, etc. arise for a variety of
reasons, both social and technical. But I _am_ arguing that just competition
is not necessarily a good thing, either, especially when competing projects
have common goals.)

~~~
Rusky
Competing for the time and interest of talented programmers means being well-
written, useful and interesting. Clang is more of a library than just a
compiler, so it doesn't have the exact same goals as GCC. I think this is a
situation where competition is a good thing- Clang will provide new, useful
tools and GCC can try to improve on them or try to offer some other kind of
advantage.

------
alanh
With all the flak Apple has taken over dropping its commitment to one "-VM,"
the JVM, I'd just like to point out Apple is the primary corporate sponsor of
LLVM (I understand). How many plates must they keep in the air? This one is
flying pretty high.

~~~
wash
I'm a 19 year old college student, actually. I have no affiliation with Apple,
nor a formal relation with Clang or LLVM.

~~~
alanh
Sorry, but your HN bio is empty and you didn't submit the article. Did you
spearhead the effort? And is my comment regarding Apple and Clang incorrect?
Thanks!

~~~
vibhavs
I'm not sure why he was downvoted. He appears to the author of the linked
email. You can see at the bottom of the mail, he signed of as "Bryce Lelbach
aka wash".

------
tzury
The LLVM project is one of those open-source project which originally aimed to
do some great things and eventually found out to do even greater.

------
brianm
FWIW, I use clang over gcc (unless there is a major overriding reason to use
gcc) just for the fabulous error messages.

<http://clang.llvm.org/diagnostics.html> gives some good examples, and my
experience has been that the examples given on that page are pretty spot on.

------
j_baker
Why would one want to do this (aside from it being a cool project)? What
advantages does clang have over gcc for kernel hacking?

~~~
wash
Clang's diagnostics and static analysis? Take, for example,
<https://patchwork.kernel.org/patch/36060/>, a serious problem in the kernel
that was recently discovered. Given the size of Linux, it would be highly
inefficient to manually find and fix every instances of this issue.

Currently, Clang doesn't support the work-around option that GCC provides to
prevent the aforementioned issue. I could just implement the GNU work-around,
but with Clang, it's far easier to write a scanner which will identify every
place in the Linux source code where those dangerous semantics appear.

Clang might not be mature enough to compile Linux for distribution. The
difference between GCC and Clang is that Clang is not a compiler. Clang is a
modular API that provides the tools to build C language front-ends to the LLVM
compiler infrastructure. The Clang compiler driver is just one implementation
of an application built using the Clang libraries.

Why would one want to do this? Well...

    
    
       http://sourceforge.net/mailarchive/message.php?msg_name=2010http://sourceforge.net/mailarchive/message.php?msg_name=20101007001758.6bcd3d3b%40Pegasus1007001758.6bcd3d3b%40Pegasus
    
       http://clang-analyzer.llvm.org/
    
       http://clang.llvm.org/docs/libIndex.html
    
       http://llvm.org/ProjectsWithLLVM/#LENS
    
       http://llvm.org/ProjectsWithLLVM/#spedi
    

Think outside of the box :)

~~~
caf
I'm pretty sure that bug was the canonical example of the usefulness of
Coccinelle in kernel development. This semantic patch was used to find and fix
all the instances of it:

    
    
        // Copyright: (C) 2009 Gilles Muller, Julia Lawall, INRIA, DIKU.  GPLv2.
        
        @@
        type T;
        expression E;
        identifier i,fld;
        statement S;
        @@
        
        - T i = E->fld;
        + T i;
          ... when != E
              when != i
          if (E == NULL) S
        + i = E->fld;
    

See <http://coccinelle.lip6.fr/impact_linux.php> for more.

~~~
wash
Oh. Well, I guess they beat me to the punch.

------
program
I am very happy. I was very pleased when back in may 20 2010 they announced
that clang passed its first fully-successful Boost regression test run. But
this is another big step ahead.

The clang static analyzer is now part of my everyday life as a programmer and
everytime I read "did you mean..." on the console I am amazed as the first
time. It saves me a lot of time (even compile time.)

------
bigmac
It looks like this was targeting an x86_64 version of the kernel. For a good
reference on LLVM-supported backends, see this table:
<http://llvm.org/docs/CodeGenerator.html#targetfeatures>

Clearly, x86 gets the most love. x86, ARM, PPC, and SPARC are listed as
"Generally Reliable." Quite an accomplishment, given the difficulty of
building up a new compiler from scratch. For now, MIPS is notably missing from
the party.

~~~
wash
Unfortunately, I'm a student with limited resources. I have three boxes, a
macbook and two Atom desktops, all x86_64.

~~~
newman314
If you promise to get things working on ARM, I might be able to get you
something.

~~~
wash
I have a 4 week break in December; I'll have ample time then to work on this.
Please shoot me an email at admin@thefireflyproject.us, so we can talk this
over some more.

------
mhd
Wasn't tcc able to do the same[1] quite a while ago?

[1]: <http://bellard.org/tcc/>

~~~
mahmud
I don't think tinycc and llvm are even in the same league in terms of
optimizations.

Tinycc is, well, _tiny_. You can get a working compiler just using syntax-
directed translation schemes and it would compile any valid program. The
output would even boot, but it would make baby-Muchnick cry.

~~~
mhd
True, no one is comparing their performance characteristics, it's just that
getting the Linux kernel to compile isn't a unique feat where you need to be
on the same level as gcc and llvm. You "just" need ANSI C with GNU extensions.
And not break on a couple dozen corner cases.

------
fleitz
It's even self hosting. This is huge.

------
ddp
This is good news. FYI, Clang/LLVM's been building FreeBSD for a while now:
<http://wiki.freebsd.org/BuildingFreeBSDWithClang>

------
rbanffy
My only worry, in the light of Oracle's spat with Google over Dalvik and its
lack of teeth over the OpenJDK, is what kind of patent protection the BSD-like
license of LLVM offers against Apple in case it decides every Linux kernel on
every non-iPhone smartphone (something that will probably happen in a couple
years) infringes some patent they have that touches LLVM in some way.

Any lawyer wants to chime in?

~~~
bramcohen
The GPL doesn't offer any special protection against third party patents, and
there's no way it could, given the way patents work.

~~~
rbanffy
I am not considering 3rd party patents, but Apple's. If Apple includes some
patented tech into a contribution to LLVM or Clang, what guarantees I have
they will not sue non-Apple downstream users?

~~~
pohl
_...in case it decides every Linux kernel on every non-iPhone
smartphone...infringes some patent they have that touches LLVM in some way._

Is there some legal precedent you know of wherein compiler patents extend to
the output of the compiler?

~~~
rbanffy
What if the output of the compiler uses some method you patented?

~~~
pohl
Then I suppose the community can fork from the revision prior to where that
patented technique landed in the tree, just as with any other OSI-approved
license.

<http://www.opensource.org/licenses/UoI-NCSA.php>

~~~
rbanffy
So, the license offers no protection at all...

~~~
pohl
Depends on one's perspective. Not long ago the _meme de jour_ was that open-
source transparency & fork-ability was the ultimate protection to corporate
evils.

By the standard you're setting, the only safe compiler would be one you wrote
yourself and revealed to no one. What compilers do you use?

------
IdeaHamster
…but it still can't compile Ruby 1.9 :-P

