No announcement yet.

AMD/Intel Benchmarks: Building The Mainline Linux x86_64 Kernel With LLVM Clang

  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    Congratulations to Clang developers, I guess. Their pipe dream has become a reality. Now they can sit in a corner and whine whenever someone breaks their builds. I'll stick with the GNU compiler, thank you very much.

    If any distro decides to compile everything with Clang because GPLv3 is supposedly bad, I'll laugh at them, and consider writing mails to companies that can tivotize their work.


    • #22
      Originally posted by staalmannen View Post

      Cool. I was also toying with the idea of a very customized LFS with basically all alternatives

      - musl instead of glibc
      - Clang, libc++ instead of gcc/stdlibc++
      - sbase/ubase instead of coreutils/linuxutils
      - nbcurses instead of ncurses
      - libedit instead of readline
      - mksh instead of bash
      - pkgsrc as package manager
      - for init: s6, runit, openrc?

      Just no time at the moment
      Nice, some projects in that list I haven’t heard of. And I hear you on the time, it’s always difficult to allocate. My plan was for at least the following:
      • muslc
      • llvm (llvm-binutils), clang
      • libc++, libedit
      • zsh
      Still looking into options for coreutils and an init system (might just go with systemd [I know], but it’s what I know). Busybox might be a good choice. I’d still like to use RPM/[dnf/zypper] for packages, but I’m open to other options.



      • #23
        Originally posted by DoMiNeLa10 View Post
        If any distro decides to compile everything with Clang because GPLv3 is supposedly bad, I'll laugh at them, and consider writing mails to companies that can tivotize their work.
        Compiling with Clang has nothing to do with GPL. Clang still uses the host C/C++ libraries, so those are what would have to be replaced. Clang is a frontend for using libstdc++ (GPL) or other options like the LLVM's project libc++/libc++abi which are not GPL. All the license on Clang does is allow application developers, like those of IDE's, the ability to ship Clang along with the app and extend it's dev toolset without having to release those changes. It has no bearing on just using it for compiling.

        Choosing to not use GNU libraries and utilities is not a strictly GPL licensing issue. There are other reasons for not using them, such as size/bloat and cross-platform compatibility/consistency. And in some situations Clang will compile faster and have more performant binaries than GCC, though that's application/load dependent.

        Last edited by mroche; 13 September 2019, 02:32 PM.


        • #24
          Originally posted by FireBurn View Post
          I've just tried builing agd5f's drm-next and didn't get any failures with clang-10 and ld.lld-10

          I did however get the following warningsL

           CC drivers/gpu/drm/amd/amdgpu/atom.o
          drivers/gpu/drm/amd/amdgpu/atom.o: warning: objtool: atom_op_move() falls through to next function atom_op_and()
          CC drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_hwss.o
          drivers/gpu/drm/amd/amdgpu/../display/dc/dce110/dce110_opp_csc_v.o: warning: objtool: dce110_opp_v_set_csc_default()+0x2ba: can't find switch jump table
          CC drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.o
          CC drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_ddc.o
          drivers/gpu/drm/amd/amdgpu/../display/dc/dce110/dce110_mem_input_v.o: warning: objtool: dce_mem_input_v_program_pte_vm()+0x254: can't find switch jump table
          CC drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_debug.o
          And this is the diff to the Makefile I used:

          diff --git a/Makefile b/Makefile
          index 23cdf1f41364..e0fa6fc10f40 100644
          --- a/Makefile
          +++ b/Makefile
          @@ -400,8 +400,8 @@ HOST_LFS_CFLAGS := $(shell getconf LFS_CFLAGS 2>/dev/null)
          HOST_LFS_LDFLAGS := $(shell getconf LFS_LDFLAGS 2>/dev/null)
          HOST_LFS_LIBS := $(shell getconf LFS_LIBS 2>/dev/null)
          -HOSTCC = gcc
          -HOSTCXX = g++
          +HOSTCC = clang
          +HOSTCXX = clang++
          KBUILD_HOSTCFLAGS := -Wall -Wmissing-prototypes -Wstrict-prototypes -O2 \
          -fomit-frame-pointer -std=gnu89 $(HOST_LFS_CFLAGS) \
          @@ -410,15 +410,15 @@ KBUILD_HOSTLDFLAGS := $(HOST_LFS_LDFLAGS) $(HOSTLDFLAGS)
          # Make variables (CC, etc...)
          -AS = $(CROSS_COMPILE)as
          -LD = $(CROSS_COMPILE)ld
          -CC = $(CROSS_COMPILE)gcc
          +AS = $(CROSS_COMPILE)llvm-as
          +LD = $(CROSS_COMPILE)ld.lld
          +CC = $(CROSS_COMPILE)clang
          CPP = $(CC) -E
          -AR = $(CROSS_COMPILE)ar
          -NM = $(CROSS_COMPILE)nm
          -STRIP = $(CROSS_COMPILE)strip
          -OBJCOPY = $(CROSS_COMPILE)objcopy
          -OBJDUMP = $(CROSS_COMPILE)objdump
          +AR = $(CROSS_COMPILE)llvm-ar
          +NM = $(CROSS_COMPILE)llvm-nm
          +STRIP = $(CROSS_COMPILE)llvm-strip
          +OBJCOPY = $(CROSS_COMPILE)llvm-objcopy
          +OBJDUMP = $(CROSS_COMPILE)llvm-objdump
          PAHOLE = pahole
          LEX = flex
          YACC = bison
          There were also these warnings:

           LD arch/x86/realmode/rm/realmode.elf
          ld.lld: warning: cannot find entry symbol _start; defaulting to 0x1000
          mm/hugetlb.c:3967:40: warning: expression does not compute the number of elements in this array; element type is 'unsigned long', not 'u32' (aka 'unsigned int') [-Wsizeof-array-div]
          hash = jhash2((u32 *)&key, sizeof(key)/sizeof(u32), 0);
          ~~~ ^
          mm/hugetlb.c:3961:16: note: array 'key' declared here
          unsigned long key[2];
          awk: ./arch/x86/tools/gen-insn-attr-x86.awk:260: warning: regexp escape sequence `\:' is not a known regexp operator
          awk: ./arch/x86/tools/gen-insn-attr-x86.awk:350: (FILENAME=./arch/x86/lib/x86-opcode-map.txt FNR=41) warning: regexp escape sequence `\&' is not a known regexp operator
          the awk one is present on a GCC build one too
          There were patches for the awk warnings on the LKML and as you noticed they were not Clang specific. If I remember correctly, the others are already known problems:

          The AMDGPU warnings sound familiar, also the realmode.elf / LLD problem. I am not sure about the hugetlb error. Please file issues at the Github repo above if you can't find them.