
Building the Linux kernel with clang - ingve
https://lwn.net/SubscriberLink/734071/f0bcc0afc5b50c85/
======
bitcharmer
This is a great step forward. Compiling with clang will allow kernel
developers to run code checks and analysis unavailable to gcc.

This will definitely have a positive effect on code quality.

Not even mentioning it should be a little bit easier to configure IDEs like
CLion for working with Linux source tree.

~~~
taeric
Is there a list of checks and analysis that you can't do from a gcc pipeline?

~~~
kevindqc
Maybe he's talking about the sanitizers? eg:
[https://clang.llvm.org/docs/AddressSanitizer.html](https://clang.llvm.org/docs/AddressSanitizer.html)

~~~
pksadiq
Those sanitizers are present in gcc too[0].

[0] [https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-
Options.h...](https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html)

~~~
ndesaulniers
Present != Equal, feature wise. Not by a long shot. At the same conf, one of
my friends who develops the sanitizers said it's easier to develop for LLVM,
so that's where Dev work is done.

~~~
pksadiq
> Present != Equal, feature wise.

It is developed by google[0] afaik. The link says it is present in LLVM and
gcc. I don't know what makes the difference (may be License?). On the contrary
I have felt gcc better for my work. I have been following a clang bug[1] for
long and have seen no fix so far.

[0]
[https://github.com/google/sanitizers/wiki/AddressSanitizer](https://github.com/google/sanitizers/wiki/AddressSanitizer)

[1]
[https://bugs.llvm.org/show_bug.cgi?id=23910](https://bugs.llvm.org/show_bug.cgi?id=23910)

~~~
pebers
Clang has better support for plugins and calling it as a library; that sort of
thing was resisted by GCC. Google has a bunch of large-scale tooling based on
the Clang frontend which AFAIK wouldn't be possible with GCC.

~~~
jcelerier
sure sure, but today (and even two years ago) you can add
-fsanitize={address,undefined,etc} on both clang and gcc. So this does not
answer the question.

------
Sir_Cmpwn
I know this isn't the opinion of many kernel developers, but I think a lot of
the problems encountered are better solved by removing proprietary GNU C
extensions from the kernel code. I would love to start sending patches but I
expect they'd just be NACKed.

~~~
taeric
Sounds like this is a prime example where evidence would help. Just thinking
"a lot of the problems..." doesn't do much to show why that is the case.
Especially without even knowing which extensions you are specifically
referring to.

That is, my guess is these extensions are the equivalent of Chesterton's
fence. They were introduced for a reason. If you have evidence that that
reason is no longer apropros, present the evidence. But don't just complain
about the fence.

~~~
Sir_Cmpwn
I mean, the problems faced by compiling the kernel with Clang (or any other
standards-implementing C compiler). The problems are pretty easy to find, just
look at the relevant commits in Clang and Linux. The main problem Clang faced
with the kernel was lots of use of GNU C extensions everywhere.

I think it's self-evident that the use of proprietary, nonstandard language
extensions is a bad idea. It leads to multi-year efforts getting other
compilers to support "features" that aren't in the spec (and as a result, are
typically _under_ speced by the compilers that implement them and require
reverse engineering to fully understand and implement correctly). Linux isn't
written in C, it's written in some other language that's deceptively similar
to C. It should be enough to write a compiler that accurately implements the C
standard to compile the kernel with.

~~~
taeric
But, I could just as easily say it is self-evident that the use of
proprietary, nonstandard languages extensions was required to get the linux
kernel written.

Don't get me wrong, I'm highly amenable to this argument, but it is not an
evidence based one.

Now, there could be some easy evidence that would help. For example, evidence
that kernels which are built using clang build just as easily using gcc. Or
icc. Or ___. That would help. Right off, I do not know if that is the case.

~~~
Sir_Cmpwn
I mean, I said it was self-evident but then provided evidence as well. Here is
the evidence:

\- Multi-year effort by Clang, a well regarded standards-compliant C compiler,
to support the kernel

\- Proprietary extensions do not conform to the same strict guidelines for
specifications as the C standard and may require reverse engineering to
implement correctly

\- C is defined by the C specification and Linux is not written in C by this
metric

\- Therefore, C compilers cannot compile the kernel

Correct me if I'm wrong but I cannot extract similar facts from your comment.

~~~
taeric
But my counter evidence was that these extensions were required to actually
build the kernel. Which is also somewhat self-evident.

So my question to you is if you have evidence that those extensions are not
required to actually build the kernel? I get that they are the "sticking"
point to moving to clang. But are they also required for the kernel to
actually do its job?

~~~
Sir_Cmpwn
I see what you mean. Yes, there are counter examples of kernels that can be
compiled without extensions. With my rough knowldge of the Linux kernel in
particular, I imagine there are a few places where the use of extensions makes
for much better code than without, and for those places the change is of
debatable utility. However, extensions are the rule rather than the exception
for the kernel. The bulk of the kernel could be written without them.

------
Koshkin
I wonder what Torvalds' opinion on Clang is. He had harsh words to say about a
recent version of gcc, as I remember.

~~~
paulddraper
IIRC, his complaints are of the nasal demon variety.

He hates compiler writers being tricky.

~~~
d33
Context:

In the C community, undefined behavior may be humorously referred to as "nasal
demons", after a comp.std.c post that explained undefined behavior as allowing
the compiler to do anything it chooses, even "to make demons fly out of your
nose".

[https://en.wikipedia.org/wiki/Undefined_behavior](https://en.wikipedia.org/wiki/Undefined_behavior)

------
MichaelMoser123
I found that clang compiled code was requiring more memory on the stack than
the same code compiling with gcc. Was it some obscure switch that did that? no
idea. However with the Linux kernel you have some tight limitations with
regard to stack size. Could the author run his clang compiled kernel? The
article does not tell.

------
benmmurphy
how do you even have VLAs where the array is the non-terminal field? do you
embed the size of the array in the type definition or in the structure?

~~~
KenoFischer
It's about whether you can put stack allocated VLAs into temporary structs:

    
    
       keno@anubis:~$ cat test2.c
       void bar(int *);
       int foo(int n) {
           struct {
               int non_terminal_val[n];
               int some_other_member;
           } val;
           bar(val.non_terminal_val);
           return val.some_other_member;
        }
        keno@anubis:~$ gcc -c test2.c
        keno@anubis:~$ clang test2.c
        test2.c:4:13: error: fields must have a constant size: 
        'variable length array in
              structure' extension will never be supported
                int non_terminal_val[n];
                    ^
        1 error generated.

~~~
gjem97
"will never be supported" I wonder how many times you have to be asked before
you put that in the error message.

------
ezoe
The Linux kernel use the variable length array in the structure which is a GCC
extension and not part of the C standard.

Clang don't want to support that GCC extension because it's too ugly.

------
swills
Given the number of operating system kernels in the world, it might be helpful
to change the title to say "the Linux kernel" instead of "the kernel". I
understand TFA is on lwn.net, which has "Linux" in it's title, so it's clear
there, but here it becomes a little vague.

~~~
sctb
OK! We've added “Linux”.

~~~
swills
Thanks!

------
wiz21c
Clang builds the kernel, EFF leaves W3C... What's next ? Amazon rewrites libc
?

~~~
pjmlp
Every C compiler has a libc.

~~~
wiz21c
I didn't know...

[https://libcxx.llvm.org/](https://libcxx.llvm.org/)

But according to what I see on that page, my interrogation remains : once the
kernel is built without gcc, then GNU's power will fade away.

GPL and HTML have, in their own ways, enforced that some important code
remains open (and sharable and modifiable). By weakening them, the openness
will be weakened too.

Of course it won't be 1000 years of darkness, but well, it makes me a bit sad
:-)

~~~
pjmlp
Why do you think Apple, Google, Sony, Nintendo and many other embedded OEMs
have moved to clang?

It wasn't only due to the better plugin support.

