(tracking bug)

(There is a patch for this in the Linux kernel patches which is being sent upstream)

Workaround: use "-mllvm -use-new-sroa=false"

Fixed in http://llvm.org/bugs/show_bug.cgi?id=14034

(Submitted fix to upstream, working on acceptance. LLVMLinux still using hack for now)

It seems that the 4.6 version of the Linaro assembler handles -march=all differently than the Android 4.6 assembler. It seems to be an issue with the version of binutils used in the Linaro toolchain (2.22 vs 2.21).

The version of the Linaro assembler that I tried (2012.07-20120720) cannot successfully build the versatile express kernel.

/llvmlinux/toolchain/clang/install/bin/clang \
-ccc-host-triple arm-none-gnueabi -ccc-gcc-name arm-linux-gnueabihf-gcc -march=armv7-a \
-mfloat-abi=softfp -mfpu=neon -fno-builtin -Wp,-MD,arch/arm/boot/compressed/.head.o.d \
-nostdinc -isystem /llvmlinux/toolchain/clang/install/bin/../lib/clang/3.2/include \
-I/llvmlinux/targets/vexpress/src/linux/arch/arm/include -Iarch/arm/include/generated \
-Iinclude -include /llvmlinux/targets/vexpress/src/linux/include/linux/kconfig.h \
-D__KERNEL__ -Iarch/arm/mach-vexpress/include -Iarch/arm/plat-versatile/include \
-D__ASSEMBLY__ -D__LINUX_ARM_ARCH__=7 -march=armv7-a -include asm/unified.h \
-msoft-float -gdwarf-2 -Wa,-march=all -DTEXT_OFFSET=0x00008000 -c -o \
arch/arm/boot/compressed/head.o arch/arm/boot/compressed/head.S
arm-linux-gnueabihf-gcc: error: unrecognized argument in option '-march=all'
arm-linux-gnueabihf-gcc: note: valid arguments to '-march=' are: armv2 armv2a armv3 armv3m \
armv4 armv4t armv5 armv5e armv5t armv5te armv6 armv6-m armv6j armv6k armv6s-m armv6t2 armv6z \
armv6zk armv7 armv7-a armv7-m armv7-r armv7e-m ep9312 iwmmxt iwmmxt2 native
clang-3: error: assembler (via gcc) command failed with exit code 1 (use -v to see invocation)
make[3]: *** [arch/arm/boot/compressed/head.o] Error 1
make[2]: *** [arch/arm/boot/compressed/vmlinux] Error 2
make[1]: *** [zImage] Error 2
make[1]: Leaving directory `/llvmlinux/targets/vexpress/src/linux'

The flag is set in arch/arm/boot/compressed/Makefile:

asflags-y := -Wa,-march=all

The error does not occur when using the Android 4.6 assembler with clang.

Linaro:

$ arm-linux-gnueabihf-as -v
GNU assembler version 2.22 (arm-linux-gnueabihf) using BFD version \
(crosstool-NG linaro-1.13.1-2012.07-20120720 - Linaro GCC 2012.07) 2.22

Android:

$ arm-linux-androideabi-as -v
GNU assembler version 2.21 (arm-linux-androideabi) using BFD version (GNU Binutils) 2.21

Interestingly, the linaro compiler can compile the kernel (without clang) as it seems to work around the problem in the gcc front end.

Linaro toolchain lead said this will be fixed in binutils 2.23. Waiting for a newrer version of the compiler based on binutils 2.23.

(Current workaround is to remove this flag, but enum lengths may not be 4 bytes)

(low priority)

(high priority)

(high priority)

(high priority)

--> Work around in the Linux Kernel patches (do_div())

Note: LLVM Bug 9387 now marked closed.

(medium priority)

(low priority)

(low priority)

(low priority)

(high priority)

"the size being stored is truncated, use a modifier to specify the size [-Wasm-operand-widths]"

Currently disabled with "-Wno-asm-operand-widths"

Work around for LLVM Bug 9254

All patches sent upstream to the various subsystem maintainers.

(Working patch but underlying cause not yet known) (x86 build issues/patch splitup block research there)

(high priority)

Update1: https://88.198.106.157/pad/p/llvm-section-mismatch

Update: works on ARM

arch/arm/boot/compressed/decompress.o: In function `zlib_inflate_table':
/rootdir/llvmlinux/targets/vexpress/src/linux/arch/arm/boot/compressed/\
../../../../lib/zlib_inflate/inftrees.c:315: undefined reference to `__stack_chk_fail'
/rootdir/llvmlinux/targets/vexpress/src/linux/arch/arm/boot/compressed/\
../../../../lib/zlib_inflate/inftrees.c:313: undefined reference to `__stack_chk_guard'
make[3]: *** [arch/arm/boot/compressed/vmlinux] Error 1)

Might be related to segment reference issues ?!

Update: retested 1/31/13 - no longer an issue for vexpress

(high priority)

#define uninitialized_var(x) x = x

Clang supports the following:

#define uninitialized_var(x) x = *(&x) 

BUILD_BUG_ON(!__builtin_constant_p(offset));

This fails for Clang and according to LLVM community arguement, should be allowed to fail. Clang can't determine this at parsing time due to the separation of the front end and back end of the compiler.

There is no clear way to implement the expected GCC behavior with clang but it is unclear if it is really needed in the first place.

(medium priority)

KBUILD_CFLAGS += $(call cc-disable-warning, unused-value)

warning-1 += $(call cc-option, -Wunused-value)

Note: Now also fixed in LLVM Bug 13747

Seems to be a warning from gas (GNU assembler). It's inline assembly code from arch/arm/include/asm/uaccess.h

/* We use 33-bit arithmetic here... */
#define __range_ok(addr,size) ({ \
       unsigned long flag, roksum; \
       __chk_user_ptr(addr);   \
       __asm__("adds %1, %2, %3; sbcccs %1, %1, %0; movcc %0, #0" \
               : "=&r" (flag), "=&r" (roksum) \
               : "r" (addr), "Ir" (size), "0" (current_thread_info()->addr_limit) \
               : "cc"); \
       flag; })

Which ends up with clang inserting something like this into it's own ASM code which gas then doesn't like.

adds r5, r1, #4; sbcccs r5, r5, r4; movcc r4, #0

This is a problem with the Linux ARM code, not with Clang nor gas.

(medium priority)

extern inline void *return_address(unsigned int)

needs to be:

extern inline __attribute__((gnu_inline)) void *return_address(unsigned int level)

/bin/sh /rootdir/llvmlinux/targets/vexpress/src/linux/scripts/mksysmap  .tmp_System.map
cmp -s System.map .tmp_System.map || (echo Inconsistent kallsyms data; \
echo This is a bug - please report about it; echo Try "make KALLSYMS_EXTRA_PASS=1" as a workaround; \
rm .tmp_kallsyms* ; /bin/false )
Inconsistent kallsyms data
This is a bug - please report about it
Try make KALLSYMS_EXTRA_PASS=1 as a workaround
make[1]: *** [vmlinux] Error 1

This seems to not be an LLVM/Clang issue. See this thread.

Changed common/arm/bin/make-kernel.sh:

$MAKE CONFIG_DEBUG_SECTION_MISMATCH=y ARCH=arm CONFIG_DEBUG_INFO=1 \
CC="$CC_FOR_BUILD" HOSTCC=$HOSTCC_FOR_BUILD ${PARALLEL}

to

$MAKE KALLSYMS_EXTRA_PASS=1 CONFIG_DEBUG_SECTION_MISMATCH=y ARCH=arm CONFIG_DEBUG_INFO=1 \
CC="$CC_FOR_BUILD" HOSTCC=$HOSTCC_FOR_BUILD ${PARALLEL}

Recently, Jan-Simon discovered that khubd kernel thread is consuming a lot of CPU. We are debugging with KGDB.