[GCC][Toolchain] Eva GCC | Calling all kernel devs!

Search This thread

Jairus980

Senior Member
Jan 18, 2016
466
1,982
24
Somewhere
  • Like
Reactions: m_vaisakh

fbs

Senior Member
Jun 22, 2007
1,084
1,045
not in brazil
Is it normal for A cc1 to use more than 8GB of ram?

root 25770 99.8 79.6 8584728 8555896 pts/1 R+ 20:57 6:53 /root/gcc-arm64-gcc-master/bin/../libexec/gcc/aarch64-elf/13.0.0/cc1 -quiet -nostdinc -I /root/tuned-j7/arch/arm64/include -I arch/arm64/include/generated -I /root/tuned-j7/include -I include -I /root/tuned-j7/arch/arm64/include/uapi -I arch/arm64/include/generated/uapi -I /root/tuned-j7/include/uapi -I include/generated/uapi -I /root/tuned-j7/mm -I mm -I /root/tuned-j7/arch/arm64/mach-exynos/include -I arch/arm64/mach-exynos/include -I /root/tuned-j7/arch/arm64/plat-samsung/include -I arch/arm64/plat-samsung/include -iprefix /root/gcc-arm64-gcc-master/bin/../lib/gcc/aarch64-elf/13.0.0/ -D __KERNEL__ -D CC_HAVE_ASM_GOTO -D KBUILD_STR(s)=#s -D KBUILD_BASENAME=KBUILD_STR(page_alloc) -D KBUILD_MODNAME=KBUILD_STR(page_alloc) -isystem /root/gcc-arm64-gcc-master/bin/../lib/gcc/aarch64-elf/13.0.0/include -include /root/tuned-j7/include/linux/kconfig.h -MD mm/.page_alloc.o.d /root/tuned-j7/mm/page_alloc.c -quiet -dumpdir mm/ -dumpbase page_alloc.c -dumpbase-ext .c -mlittle-endian -mgeneral-regs-only -mabi=lp64 -g -O2 -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -Werror=implicit-function-declaration -Wno-format-security -Wno-array-bounds -Wunused-const-variable=0 -Wno-maybe-uninitialized -Wframe-larger-than=2048 -Wno-unused-but-set-variable -Wdeclaration-after-statement -Wno-pointer-sign -std=gnu90 -fno-strict-aliasing -fno-common -fno-delete-null-pointer-checks -fdiagnostics-show-option -fno-pic -fno-stack-protector -fno-omit-frame-pointer -fno-optimize-sibling-calls -fno-var-tracking-assignments -fno-strict-overflow -fconserve-stack -o /tmp/cclX0d7X.s
 
Last edited:

fbs

Senior Member
Jun 22, 2007
1,084
1,045
not in brazil
Oh my bad I misread, can't you do a distro upgrade, I think Ubuntu had everything upgraded with latest LTS.

Man I'm in latest Ubuntu release, newer than the LTS one (Welcome to Ubuntu Kinetic Kudu (development branch).. It seems the problem is that you're compiling the compiler (lol) to be used/interpreted/read by a libc that was released only 4 days ago.. I bet only a few people on the world can execute your generated bins.

Anyway I was trying to update my libc to 2.36, to be able to run your generated code/bins, but it's almost impossible. It's not yet used by any linux distro. I would have to compile the full C library from the sources and use as an alternative C library for my system.. crazy stuff !!!
 
  • Like
Reactions: Jairus980

m_vaisakh

Recognized Developer
Man I'm in latest Ubuntu release, newer than the LTS one (Welcome to Ubuntu Kinetic Kudu (development branch).. It seems the problem is that you're compiling the compiler (lol) to be used/interpreted/read by a libc that was released only 4 days ago.. I bet only a few people on the world can execute your generated bins.

Anyway I was trying to update my libc to 2.36, to be able to run your generated code/bins, but it's almost impossible. It's not yet used by any linux distro. I would have to compile the full C library from the sources and use as an alternative C library for my system.. crazy stuff !!!
Actually my CI broke on Ubuntu, so we decided to upgrade to arch linux, and hence the mess up. Ubuntu doesn't wanna build my gcc for some weird reason lol.
 

fbs

Senior Member
Jun 22, 2007
1,084
1,045
not in brazil
Actually my CI broke on Ubuntu, so we decided to upgrade to arch linux, and hence the mess up. Ubuntu doesn't wanna build my gcc for some weird reason lol.
And arch Linux's gcc is already producing code for libc 2.36 by default? It's weird. The target libc is what is complicating things. I don't know how to change this but there must be a way, or else all binaries people release could be only run on systems with identical libc version and I've never see this happening until now lol
 

m_vaisakh

Recognized Developer
And arch Linux's gcc is already producing code for libc 2.36 by default? It's weird. The target libc is what is complicating things. I don't know how to change this but there must be a way, or else all binaries people release could be only run on systems with identical libc version and I've never see this happening until now lol
Yeah exactly my thought. I think I should switch to fedora or something.
 

Jairus980

Senior Member
Jan 18, 2016
466
1,982
24
Somewhere
#
# configuration written to .config
#
ld.lld: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.36' not found (required by ld.lld)
HOSTCC scripts/basic/fixdep
HOSTCC scripts/basic/bin2c
HOSTCC scripts/kconfig/conf.o
HOSTCC scripts/kconfig/zconf.tab.o
HOSTLD scripts/kconfig/conf
scripts/kconfig/conf --silentoldconfig Kconfig
ld.lld: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.36' not found (required by ld.lld)
CHK include/config/kernel.release



Still cant compile :(
 

m_vaisakh

Recognized Developer
#
# configuration written to .config
#
ld.lld: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.36' not found (required by ld.lld)
HOSTCC scripts/basic/fixdep
HOSTCC scripts/basic/bin2c
HOSTCC scripts/kconfig/conf.o
HOSTCC scripts/kconfig/zconf.tab.o
HOSTLD scripts/kconfig/conf
scripts/kconfig/conf --silentoldconfig Kconfig
ld.lld: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.36' not found (required by ld.lld)
CHK include/config/kernel.release



Still cant compile :(
I'm working on fixing this. You can use an older git revision for now to get gcc working.
 

Top Liked Posts

  • There are no posts matching your filters.
  • 32
    Introducing Eva GCC Toolchain

    What is GCC?
    The GNU Compiler Collection (GCC) is an optimizing compiler produced by the GNU Project supporting various programming languages, hardware architectures and operating systems. The Free Software Foundation (FSF) distributes GCC as free software under the GNU General Public License (GNU GPL). Major corporate contributors to GCC include Red Hat, IBM, SUSE, ARM, Google and Intel. GCC is a key component of the GNU toolchain and the standard compiler for most projects related to GNU and the Linux kernel. With ~15 million lines of code in 2019, GCC is one of the biggest open source programs in existence. It has played an important role in the growth of free software, as both a tool and an example.
    Source: Wikipedia

    What is LLVM Clang?
    Clang is a compiler front end for the C, C++, Objective-C and Objective-C++ programming languages, as well as the OpenMP, OpenCL, RenderScript, CUDA and HIP frameworks. It uses the LLVM compiler infrastructure as its back end and has been part of the LLVM release cycle since LLVM 2.6.
    It is designed to act as a drop-in replacement for the GNU Compiler Collection (GCC), supporting most of its compilation flags and unofficial language extensions. Its contributors include Apple, Microsoft, Google, ARM, Sony, Intel and Advanced Micro Devices (AMD). It is open-source software, with source code released under the University of Illinois/NCSA License, a permissive free software licence. Since v9.0.0, it was relicensed to the Apache License 2.0 with LLVM Exceptions.
    Source: Wikipedia

    Introduction
    Android as a whole has now fully switched to LLVM Clang for both their Platform (AOSP) and Kernels. In fact Pixel Phones have been shipping with Clang built and optimised kernels since 2018! But are there any improvements with using clang over GCC. I'd say yes, because the GCC that AOSP used was ancient (GCC 4.9). Also LLVM Clang has proven to be faster in compilation than GCC. But is this speed worth the improvement in Kernels? Let's answer that question with EvaGCC Toolchain.


    How is my toolchain different from Android GCC?
    As I've mentioned earlier, AOSP GCC is ancient (version 4.9) in terms of the present stable GCC release (10.2.x). EvaGCC is compiled straight from the Master branch, making it a Bleeding Edge C Compiler. It is built with LTO and disabled a lot of feature bloat that are unneccesary for kernel building to yield a very small binary size. To list the features:
    • Bare Metal GCC (This does not depend on the standard libc)
    • Built straight from the GNU GCC Master branch
    • Built with LTO and O3 optimisations
    • Disabled documentation (Smaller size of the toolchain)
    • Disabled decimal float, libffi, libmudflap, libquadmath, libstdcxx-pch, native language support
    • Statically linked GCC
    • Integrated LLVM LLD (For faster linking, optional)
    • Built twice weekly (Thanks to Github Actions!)

    Where can I find these toolchains?
    Well you have two options, you can compile them yourself (by using my script) or you can download precompiled binaries!
    To compile this toolchain by yourself (although I recommend that you use precompiled binaries, to avoid the hassle and time to compile the toolchain itself), to use my script to compile your toolchain, it has everything preconfigured for GCC setup and cloning. Although you'll have to setup your system for building GCC, you can refer to my README for system setup.

    Note:
    To obtain precompiled binaries (Highly recommended), head over to these links (according to your architechture and liking):
    Note: If you're doing a git clone, use --depth=1 to avoid heavy transfers, because the repositories are bound get bigger with subsequent updates.

    How do I use these toolchains for compiling my kernel
    You can either append the toolchain dir into your PATH variable, or you can just pass it along with make with setting your CROSS_COMPILE argument. I usually use the latter one.
    Since this is a bare metal compiler, the prefix differs from the normal AOSP or Linux GNU GCC. the prefix is:
    Bash:
    # Pass this to your CROSS_COMPILE argument if you have appended toolchain to your PATH
    ## for AARCH64 or ARM64
    $ make CROSS_COMPILE=aarch64-elf- ... # "..." indicates rest of your args
    
    ## for ARM
    $ make CROSS_COMPILE=arm-eabi- ...
    
    # Passing to make when you haven't appended to PATH
    ## for AARCH64 or ARM64
    $ make CROSS_COMPILE=<path to toolchain>/bin/aarch64-elf- ...
    
    ## for ARM
    $ make CROSS_COMPILE=path to toolchain>/bin/arm-eabi- ...

    Sources:
    Everything here is OSS, including the script, my ci automation script.
    GCC: https://gcc.gnu.org/git/?p=gcc.git or https://git.linaro.org/toolchain/gcc.git
    Binutils: https://sourceware.org/git/binutils-gdb.git
    GCC Build script: https://github.com/mvaisakh/gcc-build
    LLVM (Used for LLD): https://github.com/llvm/llvm-project

    GCC Version: 13.x
    Binutils Version: 2.36.x
    LLD Version: 16.x
    Telegram Channel:
    4
    NOTE: According to SultanXDA, and I quote

    GCC 10 updated its interprocedural optimizer's logic to have it make
    more conservative inlining decisions, resulting in worse syscall and
    hackbench performance compared to GCC 9.

    This can be fixed with a patch that he himself provided:

    and if that did not work for you, try applying this patch
    4
    Update 30-Jan-2021

    GCC+LLD has been merged into the main branch of the build script. Now GCC+LLD would be updated twice every week (on Sundays and Thurdays). This wasn't done before as it was under testing, and so far it only fails under LTO kernel compilation (Due to lack of GCC Plugin for LLD and vice versa).

    Update 07-April-2021

    lld-integration trunk has been merged into gcc-master branch. For those who use LLD, should switch to gcc-master as the lld-integration branch is now deprecated and will be removed soon.
    The size difference between the two isn't much (~86mb vs 125mb), so it makes sense to have a single branch for everything.
    I recommend to use zipped archive toolchains or if you use git operations to clone toolchain binaries, I recommend using --depth=1 while cloning the toolchain to avoid huge binary size cloning.

    Update 27-April-2021

    GCC Version has been bumped to 12.x
    Eva GCC
    now ships with
    GCC: 12.x
    LLD: 13.x
    BinUtils: 2.36.x

    Update 26-June-2021

    Toolchain binaries have been stripped off of debugging and hence are much smaller than before, ~90MB shaved off!
    Shallow clones shall be much faster than before!

    Update 24-Nov-2021

    LLD has been bumped to version 14.x
    GCC is still on 12.x

    Update 1-May-2022

    GCC has been bumped to version 13.x
    LLD is at 15.x
    3
    If anyone faces any issues with the toolchain, please do let me know. I will try to investigate the issue and check accordingly if it's a toolchain issue or a kernel side issue.
    Because being a cron built toolchain, it's necessary for people to report bugs as soon as possible.

    I still monitor on my end, but it's always good to have a helping hand
    2
    Update!

    GCC Version has been bumped to 12.x
    Eva GCC now ships with

    GCC: 12.x
    LLD: 13.x
    BinUtils: 2.36.x