7 ms·

Does this mean the Linux x86_64 kernel could only be built with gcc before this LLVM release? Are there any downfalls of switching from gcc -> LLVM for kernel

Does this mean the Linux x86_64 kernel could only be built with gcc before this LLVM release? Are there any downfalls of switching from gcc -> LLVM for kernel compilation? Why might somebody want to stick with gcc, why might somebody want to switch to LLVM?

cesarb 7y ago
> Does this mean the Linux x86_64 kernel could only be built with gcc before this LLVM release? It was already possible to compile the kernel with clang/llvm. But a few releases ago, the Linux kernel dropped support for being built with older compilers which did not have support for the "asm goto" gcc extension. The Linux kernel has always targeted gcc exclusively, and makes heavy use of gcc extensions since its very first release. The only reason clang can compile the Linux kernel is that the clang developers implemented support for the many gcc extensions the Linux kernel uses.
- The_rationalist 7y ago
  Interesting so this means that if someone really want llvm to support an extension (say a C attribute) that GCC supports, then you "just" have to make a contribution to the Linux kernel that use the gcc attribute and that is a minimum useful. Then LLVM will prioritize the support of said attribute. As such, hardcore developers might become new Linux contributors just as an Indirect (but effective) way to force LLVM/clang to add support for an attribute.
  - chc 7y ago
    Who in the world would do that rather than just supporting both compilers?
    - The_rationalist 7y ago
      You don't seems to understand that extensions/attributes can have a usefulness that far outweight cross compiler compatibility? Type of reasons: Performance critical; Security; Expressivity; Each of them can be a necessary reason. E.g "polymorphism" in C through transparent unions
  - spacepinball 7y ago
    Rational indeed
  - sanxiyn 7y ago
    Yes, this is in fact a viable strategy. Source: I contributed a few GCC extension in Clang forced by Linux kernel.
pjmlp 7y ago
Mainstream yes. Android has moved to clang for quite a while now, the Linux kernel is the only GPL piece left.
- steeleduncan 7y ago
  Fuschia seems to be non-GPL. Are Google trying to remove GPL entirely from Android?
  - pjmlp 7y ago
    Every major corporation is trying to get rid of GPL. On the embedded market Linux is competing against alternatives like mbed, RTOS, Zephyr, NuttX. In a couple of more years, we will be back to days of public domain and freeware, a subset of features free and the enticing ones all closed source. Or running in some cloud (aka mainframe), with the only open part being the browser code, or not even that depending how WebAssembly + WebGL/WebGPU happen to evolve (depending on how Google and Apple feel like driving it). Then the anti-GPL crowd might remember the days that they got GCC, GNU and the Linux kernel, or maybe not. Although for many of us that deal daily with commercial software that is kind of irrelevant anyway.
    - est31 7y ago
      The biggest issue of fuchsia isn't its license, it's rather the design choice to allow proprietary driver blobs. Linux, for the exception of a few blobs here and there, rejects such an idea. In other words, the question is less about license and more about attitude / tolerance for proprietary extensions/tooling. The main power that an open source maintainer has is the design of the codebase and what to accept inside, not the power to litigate a copyleft license. The more it cooperates with proprietary software, the more likely proprietary software can establish itself and restrict user freedoms.
      - pjmlp 7y ago
        Google has already achieved that with Project Treble by the way.
ndesaulniers 7y ago
No but it's complicated. We shipped ARM64 clang built linux kernels with clang-4.0 in Google Pixel 2. x86_64 was buildable up until ~4.20 Linux kernel release. (so we could build 4.4, 4.9, 4.14, and 4.19 LTS x86_64 kernels pre-clang-9). The x86_64 maintainers required the use of CONFIG_JUMP_LABEL/asm goto in the 4.20 kernel release IIRC. Certain configs and drivers needed compiler fixes. Pretty soon we'll be moving Android and ChromeOS' arm32 kernels over to Clang as well. CONFIG_FUNCTION_TRACER makes the compiler emit __gnu_mcount_nc calls with a non-standard calling convention just on arm32. You should have seen the Apple reviewer's reaction to the LLVM patch implementing support in LLVM for that! There's also traces of code in the kernel that suggest it was once build-able with ICC at one point. The code looks broken to me and I suspect it doesn't work. That said, if anyone knows anyone compiling the Linux kernel with ICC, I'd love to get in touch.
- ComputerGuru 7y ago
  I want to say Intel was advertising compiling the kernel with ICC around 2009 or so. (ICC and I parted ways around 2010).

cesarb 7y ago

> Does this mean the Linux x86_64 kernel could only be built with gcc before this LLVM release? It was already possible to compile the kernel with clang/llvm. But a few releases ago, the Linux kernel dropped support for being built with older compilers which did not have support for the "asm goto" gcc extension. The Linux kernel has always targeted gcc exclusively, and makes heavy use of gcc extensions since its very first release. The only reason clang can compile the Linux kernel is that the clang developers implemented support for the many gcc extensions the Linux kernel uses.

The_rationalist 7y ago
Interesting so this means that if someone really want llvm to support an extension (say a C attribute) that GCC supports, then you "just" have to make a contribution to the Linux kernel that use the gcc attribute and that is a minimum useful. Then LLVM will prioritize the support of said attribute. As such, hardcore developers might become new Linux contributors just as an Indirect (but effective) way to force LLVM/clang to add support for an attribute.
- chc 7y ago
  Who in the world would do that rather than just supporting both compilers?
  - The_rationalist 7y ago
    You don't seems to understand that extensions/attributes can have a usefulness that far outweight cross compiler compatibility? Type of reasons: Performance critical; Security; Expressivity; Each of them can be a necessary reason. E.g "polymorphism" in C through transparent unions
- spacepinball 7y ago
  Rational indeed
- sanxiyn 7y ago
  Yes, this is in fact a viable strategy. Source: I contributed a few GCC extension in Clang forced by Linux kernel.

pjmlp 7y ago

Mainstream yes. Android has moved to clang for quite a while now, the Linux kernel is the only GPL piece left.

steeleduncan 7y ago
Fuschia seems to be non-GPL. Are Google trying to remove GPL entirely from Android?
- pjmlp 7y ago
  Every major corporation is trying to get rid of GPL. On the embedded market Linux is competing against alternatives like mbed, RTOS, Zephyr, NuttX. In a couple of more years, we will be back to days of public domain and freeware, a subset of features free and the enticing ones all closed source. Or running in some cloud (aka mainframe), with the only open part being the browser code, or not even that depending how WebAssembly + WebGL/WebGPU happen to evolve (depending on how Google and Apple feel like driving it). Then the anti-GPL crowd might remember the days that they got GCC, GNU and the Linux kernel, or maybe not. Although for many of us that deal daily with commercial software that is kind of irrelevant anyway.
  - est31 7y ago
    The biggest issue of fuchsia isn't its license, it's rather the design choice to allow proprietary driver blobs. Linux, for the exception of a few blobs here and there, rejects such an idea. In other words, the question is less about license and more about attitude / tolerance for proprietary extensions/tooling. The main power that an open source maintainer has is the design of the codebase and what to accept inside, not the power to litigate a copyleft license. The more it cooperates with proprietary software, the more likely proprietary software can establish itself and restrict user freedoms.
    - pjmlp 7y ago
      Google has already achieved that with Project Treble by the way.

ndesaulniers 7y ago

No but it's complicated. We shipped ARM64 clang built linux kernels with clang-4.0 in Google Pixel 2. x86_64 was buildable up until ~4.20 Linux kernel release. (so we could build 4.4, 4.9, 4.14, and 4.19 LTS x86_64 kernels pre-clang-9). The x86_64 maintainers required the use of CONFIG_JUMP_LABEL/asm goto in the 4.20 kernel release IIRC. Certain configs and drivers needed compiler fixes. Pretty soon we'll be moving Android and ChromeOS' arm32 kernels over to Clang as well. CONFIG_FUNCTION_TRACER makes the compiler emit __gnu_mcount_nc calls with a non-standard calling convention just on arm32. You should have seen the Apple reviewer's reaction to the LLVM patch implementing support in LLVM for that! There's also traces of code in the kernel that suggest it was once build-able with ICC at one point. The code looks broken to me and I suspect it doesn't work. That said, if anyone knows anyone compiling the Linux kernel with ICC, I'd love to get in touch.

ComputerGuru 7y ago
I want to say Intel was advertising compiling the kernel with ICC around 2009 or so. (ICC and I parted ways around 2010).