All Projects → kdrag0n → Proton Clang

kdrag0n / Proton Clang

Licence: other
Proton Clang toolchains builds in the form of a continuously updating Git repository. Clone with --depth=1.

Programming Languages

c
50402 projects - #5 most used programming language

Projects that are alternatives of or similar to Proton Clang

Meta Clang
Clang C/C++ cross compiler and runtime for OpenEmbedded/Yocto Project
Stars: ✭ 76 (-39.68%)
Mutual labels:  llvm, clang, cross-compiler
Bsodsurvivor
This project aims to facilitate debugging a kernel driver in windows by adding support for a code change on the fly without reboot/unload, and more!
Stars: ✭ 122 (-3.17%)
Mutual labels:  llvm, clang, kernel
Optviewer Demo
Demonstration of LLVM's opt-viewer tool
Stars: ✭ 63 (-50%)
Mutual labels:  llvm, clang
Avalonstudio
Cross platform IDE and Shell
Stars: ✭ 1,132 (+798.41%)
Mutual labels:  llvm, clang
Llvm Utils
LLVM/Clang for Visual Studio 2019, 2017, 2015, 2013, 2012 and 2010. clang-cl for Python3 distutils. Utils for Clang Static Analyzer
Stars: ✭ 123 (-2.38%)
Mutual labels:  llvm, clang
Llvm 9.0 Learner Tutorial
A blog for LLVM(v9.0.0 or v11.0.0) beginner, step by step, with detailed documents and comments. Record the way I learn LLVM and accomplish a complete project for FPGA High-Level Synthesis with it.
Stars: ✭ 58 (-53.97%)
Mutual labels:  llvm, clang
Cxxctp
DEPRECATED. USE INSTEAD github.com/blockspacer/flextool
Stars: ✭ 58 (-53.97%)
Mutual labels:  llvm, clang
Seeless
C IDE for iOS
Stars: ✭ 71 (-43.65%)
Mutual labels:  llvm, clang
Enzyme
High-performance automatic differentiation of LLVM.
Stars: ✭ 418 (+231.75%)
Mutual labels:  llvm, clang
Termux Ndk
android-ndk for termux
Stars: ✭ 91 (-27.78%)
Mutual labels:  llvm, clang
Llvm Vs2017 Integration
MSBuild 15.0 Toolset integration for multiple LLVM (From v5 to v8)
Stars: ✭ 84 (-33.33%)
Mutual labels:  llvm, clang
Tre
LLVM backed progamming language (Go subset)
Stars: ✭ 100 (-20.63%)
Mutual labels:  llvm, clang
C2goasm
C to Go Assembly
Stars: ✭ 1,072 (+750.79%)
Mutual labels:  llvm, clang
Woboq codebrowser
Woboq CodeBrowser
Stars: ✭ 837 (+564.29%)
Mutual labels:  llvm, clang
Zapcc
zapcc is a caching C++ compiler based on clang, designed to perform faster compilations
Stars: ✭ 1,109 (+780.16%)
Mutual labels:  llvm, clang
Fcd
An optimizing decompiler
Stars: ✭ 622 (+393.65%)
Mutual labels:  llvm, clang
Swiftweekly.github.io
A community-driven weekly newsletter about Swift.org
Stars: ✭ 305 (+142.06%)
Mutual labels:  llvm, clang
Clangkit
ClangKit provides an Objective-C frontend to LibClang. Source tokenization, diagnostics and fix-its are actually implemented.
Stars: ✭ 330 (+161.9%)
Mutual labels:  llvm, clang
Codechecker
CodeChecker is an analyzer tooling, defect database and viewer extension for the Clang Static Analyzer and Clang Tidy
Stars: ✭ 1,209 (+859.52%)
Mutual labels:  llvm, clang
Cppinsights
C++ Insights - See your source code with the eyes of a compiler
Stars: ✭ 1,382 (+996.83%)
Mutual labels:  llvm, clang

Proton Clang

This is a LLVM and Clang compiler toolchain built for kernel development. Builds are always made from the latest LLVM sources rather than stable releases, so complete stability cannot be guaranteed.

This toolchain targets the AArch32, AArch64, and x86 architectures. It is built with LTO and PGO to reduce compile times as much as possible. Polly, LLVM's polyhedral loop optimizer, is also included for users who want to experiment with additional optimization. Note that this toolchain is not suitable for anything other than bare-metal development; it has not been built with support for any libc or userspace development in mind.

binutils is also included for convenience. Unlike LLVM, however, the latest stable version of binutils is always used to reduce the opportunity for breakage because this project is primarily focused on cutting-edge Clang, not binutils. This means that users do not need to download separate GCC toolchains to build the Linux kernel.

Automated builds occur weekly at 3 PM PST on every Saturday using fresh sources from the LLVM Git monorepo. If any part of the builds fail, this repository will not be updated. The build scripts (powered by tc-build) behind this can be found here.

Build notifications and other information can be obtained from the Telegram channel.

Host compatibility

This toolchain is built on Ubuntu 18.04 LTS, which uses glibc 2.27. Compatibility with older distributions cannot be guaranteed. Other libc implementations (such as musl) are not supported.

Building Linux

Make sure you have this toolchain in your PATH:

export PATH="$HOME/toolchains/proton-clang/bin:$PATH"

For an AArch64 cross-compilation setup, you must set the following variables. Some of them can be environment variables, but some must be passed directly to make as a command-line argument. It is recommended to pass all of them as make arguments to avoid confusing errors:

  • CC=clang (must be passed directly to make)
  • CROSS_COMPILE=aarch64-linux-gnu-
  • If your kernel has a 32-bit vDSO: CROSS_COMPILE_ARM32=arm-linux-gnueabi-

Optionally, you can also choose to use as many LLVM tools as possible to reduce reliance on binutils. All of these must be passed directly to make:

  • AR=llvm-ar
  • NM=llvm-nm
  • OBJCOPY=llvm-objcopy
  • OBJDUMP=llvm-objdump
  • STRIP=llvm-strip

Note, however, that additional kernel patches may be required for these LLVM tools to work. It is also possible to replace the binutils linkers (lf.bfd and ld.gold) with lld and use Clang's integrated assembler for inline assembly in C code, but that will require many more kernel patches and it is currently impossible to use the integrated assembler for all assembly code in the kernel.

Android kernels older than 4.14 will require patches for compiling with any Clang toolchain to work; those patches are out of the scope of this project. See android-kernel-clang for more information.

Android kernels 4.19 and newer use the upstream variable CROSS_COMPILE_COMPAT. When building these kernels, replace CROSS_COMPILE_ARM32 in your commands and scripts with CROSS_COMPILE_COMPAT.

Differences from other toolchains

Proton Clang has been designed to be easy-to-use compared to other toolchains, such as AOSP Clang. The differences are as follows:

  • CLANG_TRIPLE does not need to be set because we don't use AOSP binutils
  • LD_LIBRARY_PATH does not need to be set because we set library load paths in the toolchain
  • No separate GCC/binutils toolchains are necessary; all tools are bundled

Common problems

as: unrecognized option '-EL'

Usually, this means that CROSS_COMPILE is not set correctly. Check that variable as well as your PATH to make sure that the required tools are available for Clang to invoke. You can test it manually like tihs:

$ ${CROSS_COMPILE}ld -v
GNU ld (GNU Binutils) 2.34

If you see Command not found or any other error, one of the two variables mentioned above is most likely set incorrectly.

If you continue to encounter this error after verifying CROSS_COMPILE and PATH, you are probably running into a change in Clang 12's handling of cross-compiling. The fix is to either merge linux-stable (which already has the fix included) cherry-pick "Makefile: Fix GCC_TOOLCHAIN_DIR prefix for Clang cross compilation" manually.

If the error still continues to appear and you have an arm64 kernel that includes vdso32, you will also need to cherry-pick "arm64: vdso32: Fix '--prefix=' value for newer versions of clang" to fix the second vdso32 error. Merging linux-stable is also an option if you are on Linux 5.4 or newer.

Cannot use CONFIG_CC_STACKPROTECTOR_STRONG: -fstack-protector-strong not supported by compiler

This error is actually a result of stack protector checks in the Makefile that cause the real error to be masked. It indicates that one or more unsupported compiler flags have been passed to Clang. Disable CONFIG_CC_STACKPROTECTOR_STRONG in favor of CONFIG_CC_STACKPROTECTOR_NONE temporarily (make sure you don't keep this change permanently for security reasons) and Clang will output the flag that is causing the problem.

In downstream kernels, the cause is usually big.LITTLE CPU optimization flags that have been added to the Makefile unconditionally. The correct solution is to check cc-name for the current compiler and adjust the optimization flags accordingly — big.LITTLE for GCC and little-only for Clang. See "Makefile: Optimize for sm8150's Kryo 485 CPU setup" for an example implementation of this.

scripts/gcc-version.sh: line 25: aarch64-linux-gnu-gcc: command not found

This is caused by unconditional invocations of gcc-version.sh in CAF's camera_v2 driver. The recommended solution is to cherry-pick Google's fix from the Pixel 2 kernel, which simply removes the faulty invocations as they were never useful to begin with.

Note that these errors are harmless and don't necessarily need to be fixed, but nonetheless, ignoring them is not recommended.

undefined reference to 'stpcpy'

This is caused by a libcall optimization added in Clang 12 that optimizes certain basic sprintf calls into stpcpy calls. The correct fix for this is to cherry-pick "lib/string.c: implement stpcpy", which adds a simple implementation of stpcpy to the kernel so that Clang can use it.

Note that the project description data, including the texts, logos, images, and/or trademarks, for each open source project belongs to its rightful owner. If you wish to add or remove any projects, please contact us at [email protected].