4 ms·

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

by j_baker 16y ago

hendler 16y ago
(disclaimer: I can't answer this with authority) The reasons I get excited: * speed: faster compilation * research: interesting code introspection you can't get from GCC. * proof of concept: if you can build the linux kernel, you can probably build almost any C project * edit: as mentioned in other comments, competition is good.
Legion 16y ago
This isn't a "hey, go do this" post. This is a milestone in the development of Clang.
- j_baker 16y ago
  Of course. I was just curious if this had any other value.
fleitz 16y ago
It may make certain bugs more apparent. If you have development going on with a different compiler and it's actively maintained to work on both compilers then overall you'd get similar advantages in your code base to those that write cross-platform software. Incidentally, you get the same effect with cross-platform as you're usually targeting different compilers. Also, with less compiler specific code it will be easier to get the kernel working with other compilers, perhaps ICC.
- mzl 16y ago
  Unfortunately, Clang is still a bit shaky at times. In our (C++) project, we get a miscompilation in Clang that we don't get with gcc, the visual studio compiler, nor the intel compiler. It will be great when it is more stable: clang cuts the compile time by half in comparison with gcc (from 18 minutes to 9 minutes on my computer).
  - X-Istence 16y ago
    File a bug report. They are very receptive of them. Especially if you get a miscompilation.
    - mzl 16y ago
      I hope to do so, I really like the project and want it to succeed. Unfortunately, I'm not yet sure how to reduce the 100000 lines to something manageable with the problem clear :)
      - sparky 16y ago
        Do you suspect the bug to be in clang (the front-end) itself, or in LLVM's optimizer or back-end? For the latter cases, bugpoint is included in the LLVM source tree and does a good job of narrowing things down, so long as you provide a program whose output should be deterministic (this may involve some work on your part if your program usually depends on data from the outside world). It is described here http://llvm.org/docs/Bugpoint.html http://llvm.org/docs/Bugpoint.html . It may be useful for Clang bugs too, I'm not sure. People may help you by suggesting strategies for finding a small test case that tickles the same problem if you post to the mailing list here http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev . I've posted a couple times and found people surprisingly responsive and helpful.
        mzl 16y ago
        That looks like an interesting tool, I'll have to try it out. The program is deterministic given a fixed seed. The bug depends on whether or not optimization is on, so it might be in the backend. What I've heard is that the C++ FE in particular still does have some troubles with miscompilations, so that is why I suspect it.
  - chc 16y ago
    Clang is really good at C and Objective-C. C++ is kind of its weak point, most likely because C++ is a couple of orders of magnitude more complex than either of those languages.
aidenn0 16y ago
In general having 2 compatible implementations with little or no shared-code base allows for more easily finding bugs in your code. A lot of times bugs won't show up in testing because one compiler just happens to mask them. This isn't always a problem, since the bugs may stay masked. However, in a changing codebase they are likely to pop up in the future.
btilly 16y ago
I think that http://blog.llvm.org/2010/04/amazing-feats-of-clang-error-recovery.html http://blog.llvm.org/2010/04/amazing-feats-of-clang-error-re... gives a number of nice features that clang brings to the table which could be very useful for kernel hackers.
wash 16y ago
Clang's diagnostics and static analysis? Take, for example, https://patchwork.kernel.org/patch/36060/ 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 16y ago
  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 http://coccinelle.lip6.fr/impact_linux.php for more.
  - wash 16y ago
    Oh. Well, I guess they beat me to the punch.

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

by j_baker 16y ago

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

hendler 16y ago

(disclaimer: I can't answer this with authority) The reasons I get excited: * speed: faster compilation * research: interesting code introspection you can't get from GCC. * proof of concept: if you can build the linux kernel, you can probably build almost any C project * edit: as mentioned in other comments, competition is good.

Legion 16y ago

This isn't a "hey, go do this" post. This is a milestone in the development of Clang.

j_baker 16y ago
Of course. I was just curious if this had any other value.

fleitz 16y ago

It may make certain bugs more apparent. If you have development going on with a different compiler and it's actively maintained to work on both compilers then overall you'd get similar advantages in your code base to those that write cross-platform software. Incidentally, you get the same effect with cross-platform as you're usually targeting different compilers. Also, with less compiler specific code it will be easier to get the kernel working with other compilers, perhaps ICC.

mzl 16y ago
Unfortunately, Clang is still a bit shaky at times. In our (C++) project, we get a miscompilation in Clang that we don't get with gcc, the visual studio compiler, nor the intel compiler. It will be great when it is more stable: clang cuts the compile time by half in comparison with gcc (from 18 minutes to 9 minutes on my computer).
- X-Istence 16y ago
  File a bug report. They are very receptive of them. Especially if you get a miscompilation.
  - mzl 16y ago
    I hope to do so, I really like the project and want it to succeed. Unfortunately, I'm not yet sure how to reduce the 100000 lines to something manageable with the problem clear :)
    - sparky 16y ago
      Do you suspect the bug to be in clang (the front-end) itself, or in LLVM's optimizer or back-end? For the latter cases, bugpoint is included in the LLVM source tree and does a good job of narrowing things down, so long as you provide a program whose output should be deterministic (this may involve some work on your part if your program usually depends on data from the outside world). It is described here http://llvm.org/docs/Bugpoint.html http://llvm.org/docs/Bugpoint.html . It may be useful for Clang bugs too, I'm not sure. People may help you by suggesting strategies for finding a small test case that tickles the same problem if you post to the mailing list here http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev . I've posted a couple times and found people surprisingly responsive and helpful.
      - mzl 16y ago
        That looks like an interesting tool, I'll have to try it out. The program is deterministic given a fixed seed. The bug depends on whether or not optimization is on, so it might be in the backend. What I've heard is that the C++ FE in particular still does have some troubles with miscompilations, so that is why I suspect it.
- chc 16y ago
  Clang is really good at C and Objective-C. C++ is kind of its weak point, most likely because C++ is a couple of orders of magnitude more complex than either of those languages.

aidenn0 16y ago

In general having 2 compatible implementations with little or no shared-code base allows for more easily finding bugs in your code. A lot of times bugs won't show up in testing because one compiler just happens to mask them. This isn't always a problem, since the bugs may stay masked. However, in a changing codebase they are likely to pop up in the future.

btilly 16y ago

I think that http://blog.llvm.org/2010/04/amazing-feats-of-clang-error-recovery.html http://blog.llvm.org/2010/04/amazing-feats-of-clang-error-re... gives a number of nice features that clang brings to the table which could be very useful for kernel hackers.

wash 16y ago

Clang's diagnostics and static analysis? Take, for example, https://patchwork.kernel.org/patch/36060/ 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 16y ago
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 http://coccinelle.lip6.fr/impact_linux.php for more.
- wash 16y ago
  Oh. Well, I guess they beat me to the punch.