[llvmlinux] Rebasing llvmlinux kernel patches to more current kernels

Sedat Dilek sedat.dilek at gmail.com
Wed Apr 6 09:13:36 UTC 2016


On Wed, Apr 6, 2016 at 4:09 AM, Bernhard Rosenkränzer
<bernhard.rosenkranzer at linaro.org> wrote:
> Hi,
> some good news - Linaro is now officially interested in building kernels
> with clang.
>
> Our initial target will be getting the HiKey board booting AOSP with both
> kernel and userland compiled with clang.
>
> I've created a git repository, initially rebasing the llvmlinux patches to
> the HiKey kernel (which is essentially 4.4.0 + AOSP patches + some extra
> hardware support patches - while untested, it should be possible to just
> build that kernel for x86 as well) at
>

Hi Berhard,

thanks for your new impulse on Linux and llvm-toolchain.

I am interested in Linux v4.4 LTS and X86_64 aka AMD64.
Also interested in using stable LLVM/Clang version - not latest Git upstream.
Currently, I use llvm-toolchain v3.8.

There are several issue not solved (see for example [1]) and real show-stopper!
One of you commented below.

> git://android-git.linaro.org/kernel/hikey-clang.git
>

Do you have a GitWeb-URL which I can browse with my Firefox?

> The interesting branch is android-hikey-linaro-4.4-clang - the upstream
> non-clang-buildable kernel sits in the android-hikey-linaro-4.4 branch in
> case anyone wants to git format-patch or the likes.
>
> The patchset is quite a bit smaller than what's on llvmlinux-current -
> almost half the patches that used to be there have either been merged or
> obsoleted.
>
> My rebased tree is almost buildable again (at least in the HiKey config) -
> with clang 3.8, the HiKey target compiles, but fails during linking stage.
>
> I'm currently at ELC and won't have a lot of time to continue from there for
> a couple of days - has anyone run into (or even fixed) these errors before?
>
> arch/arm64/kernel/built-in.o: In function `debug_monitors_arch':
> /home/bero/repos/linux/arch/arm64/kernel/debug-monitors.c:36: undefined
> reference to `mcount'
> /home/bero/repos/linux/arch/arm64/kernel/debug-monitors.c:36:(.text+0xc):
> relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol
> `mcount'
> /home/bero/repos/linux/arch/arm64/kernel/debug-monitors.c:37: undefined
> reference to `mcount'
> /home/bero/repos/linux/arch/arm64/kernel/debug-monitors.c:37:(.text+0x20):
> relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol
> `mcount'
> arch/arm64/kernel/built-in.o: In function `cpuid_feature_extract_field':
> /home/bero/repos/linux/./arch/arm64/include/asm/cpufeature.h:128: undefined
> reference to `mcount'
> /home/bero/repos/linux/./arch/arm64/include/asm/cpufeature.h:128:(.text+0x24):
> relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol
> `mcount'
> arch/arm64/kernel/built-in.o: In function `create_debug_debugfs_entry':
> /home/bero/repos/linux/arch/arm64/kernel/debug-monitors.c:66: undefined
> reference to `mcount'
> /home/bero/repos/linux/arch/arm64/kernel/debug-monitors.c:66:(.text+0x40):
> relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol
> `mcount'
> arch/arm64/kernel/built-in.o: In function `enable_debug_monitors':
> /home/bero/repos/linux/arch/arm64/kernel/debug-monitors.c:88: undefined
> reference to `mcount'
> /home/bero/repos/linux/arch/arm64/kernel/debug-monitors.c:88:(.text+0x80):
> relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol
> `mcount'
> arch/arm64/kernel/built-in.o:/home/bero/repos/linux/arch/arm64/kernel/debug-monitors.c:91:
> more undefined references to `mcount' follow
> arch/arm64/kernel/built-in.o: In function `enable_debug_monitors':
> /home/bero/repos/linux/arch/arm64/kernel/debug-monitors.c:91:(.text+0x84):
> relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol
> `mcount'
> arch/arm64/kernel/built-in.o: In function `preempt_count':
> /home/bero/repos/linux/include/asm-generic/preempt.h:10:(.text+0x88):
> relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol
> `mcount'
> arch/arm64/kernel/built-in.o: In function `enable_debug_monitors':
> /home/bero/repos/linux/arch/arm64/kernel/debug-monitors.c:91:(.text+0x9c):
> relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol
> `mcount'
> /home/bero/repos/linux/arch/arm64/kernel/debug-monitors.c:91:(.text+0xa4):
> relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol
> `mcount'
> /home/bero/repos/linux/arch/arm64/kernel/debug-monitors.c:93:(.text+0xbc):
> relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol
> `mcount'

That mcount is a known issue and derives from function-tracer enabled.
I recommend to try CONFIG_FTRACE=n.
There exists a BUG-number in the LLVM-BTS (PaX) on this (not off-hand
right now).

> /home/bero/repos/linux/arch/arm64/kernel/debug-monitors.c:93:(.text+0xc4):
> additional relocation overflows omitted from the output
> aarch64-mandriva-linux-gnu-ld: Dwarf Error: Info pointer extends beyond end
> of attributes
> aarch64-mandriva-linux-gnu-ld: Dwarf Error: Info pointer extends beyond end
> of attributes
> aarch64-mandriva-linux-gnu-ld: Dwarf Error: Info pointer extends beyond end
> of attributes
> aarch64-mandriva-linux-gnu-ld: Dwarf Error: Info pointer extends beyond end
> of attributes
> aarch64-mandriva-linux-gnu-ld: Dwarf Error: Info pointer extends beyond end
> of attributes
> aarch64-mandriva-linux-gnu-ld: Dwarf Error: Info pointer extends beyond end
> of attributes
> aarch64-mandriva-linux-gnu-ld: Dwarf Error: Info pointer extends beyond end
> of attributes
> aarch64-mandriva-linux-gnu-ld: Dwarf Error: Info pointer extends beyond end
> of attributes
> aarch64-mandriva-linux-gnu-ld: Dwarf Error: Info pointer extends beyond end
> of attributes
> aarch64-mandriva-linux-gnu-ld: Dwarf Error: Info pointer extends beyond end
> of attributes
> aarch64-mandriva-linux-gnu-ld: Dwarf Error: Info pointer extends beyond end
> of attributes
> aarch64-mandriva-linux-gnu-ld: Dwarf Error: Info pointer extends beyond end
> of attributes
> aarch64-mandriva-linux-gnu-ld: Dwarf Error: Info pointer extends beyond end
> of attributes
> aarch64-mandriva-linux-gnu-ld: Dwarf Error: Info pointer extends beyond end
> of attributes
> aarch64-mandriva-linux-gnu-ld: Dwarf Error: Info pointer extends beyond end
> of attributes
> aarch64-mandriva-linux-gnu-ld: Dwarf Error: Info pointer extends beyond end
> of attributes
> aarch64-mandriva-linux-gnu-ld: Dwarf Error: Info pointer extends beyond end
> of attributes
> drivers/built-in.o: In function `__acpi_processor_start':
> /home/bero/repos/linux/drivers/acpi/processor_driver.c:250: undefined
> reference to `acpi_idle_driver'
> /home/bero/repos/linux/drivers/acpi/processor_driver.c:250: undefined
> reference to `acpi_idle_driver'
> /home/bero/repos/linux/drivers/acpi/processor_driver.c:251: undefined
> reference to `mcount'
> /home/bero/repos/linux/drivers/acpi/processor_driver.c:253: undefined
> reference to `mcount'
> /home/bero/repos/linux/drivers/acpi/processor_driver.c:263: undefined
> reference to `mcount'
> drivers/built-in.o: In function `acpi_processor_notify':
> /home/bero/repos/linux/drivers/acpi/processor_driver.c:70: undefined
> reference to `mcount'
> /home/bero/repos/linux/drivers/acpi/processor_driver.c:78: undefined
> reference to `mcount'
> drivers/built-in.o:/home/bero/repos/linux/drivers/acpi/processor_driver.c:89:
> more undefined references to `mcount' follow
>
>
> Build instructions for HiKey are pretty much as expected:
> make CC=clang HOSTCC=clang CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64
> hikey_defconfig
> make CC=clang HOSTCC=clang CROSS_COMPILE=aarch64-linux-gnu- ARCH=arm64 -j24
>
> Once HiKey is working, will also rebase the patches to master.
>
> There's a gerrit server connected to the repository as well,
> http://android-review.linaro.org/ - if anyone has patches to contribute,
> please submit them either there or send a pull request or use the ML.
>

So you have your own and new places.
The question for me is where to do the further development?
LLVMLinux was recently removed from Linux-next as there was no commits
since one year.
LLVMLinux is not my choice - my questions rest unanswered in the sense
of "not solved".
On Linux/x86 experts on both sides (Linux-kernel and llvm-toolchain) are needed.
Some BUG-reports are so old, I could cry.

I am talking about a new strategy and solutions.
Do you want to start something new and (in)vita(b)l(e)?

I had some issues which I could really narrow down with Linux-kernel
(x86, usb) folks, not here.
>From this list PaX and David Woodhouse where helpful - on X86 - I am
focused on X86 as said.
I cannot help with ARM/ARM64 - I have a Google Nexus 4 here which is not in use.

Really not sure if I am willing to join any "Linux-with-Clang"
projects (life-time and nerves).
Not sure to get the big bosses involved.
Do not forget this here is a Linux Foundation project!

Regards,
- Sedat Dilek -

[1] http://marc.info/?t=145682693700001&r=1&w=2


More information about the LLVMLinux mailing list