[llvmlinux] Compilation errors android msm-caf-nexus5 and oneplus one
Fürst Stefan
dieb.stefan.96 at gmail.com
Fri Aug 28 16:14:33 UTC 2015
Hello,
i just build LLVM and Clang in release mod. Than i recompiled my kernel
with it.
But i stil get these errors.
arch/arm/kernel/built-in.o: In function `copy_thread':
/home/stefan/build/kernels/one_plus_one/arch/arm/kernel/process.c:576:
undefined reference to `__aeabi_memcpy4'
arch/arm/kernel/built-in.o: In function `elf_core_copy_regs':
/home/stefan/build/kernels/one_plus_one/include/linux/elfcore.h:113:
undefined reference to `__aeabi_memcpy4'
arch/arm/kernel/built-in.o: In function `put_user_reg':
/home/stefan/build/kernels/one_plus_one/arch/arm/kernel/ptrace.c:177:
undefined reference to `__aeabi_memcpy4'
arch/arm/kernel/built-in.o: In function `gpr_set':
/home/stefan/build/kernels/one_plus_one/arch/arm/kernel/ptrace.c:610:
undefined reference to `__aeabi_memcpy4'
arch/arm/kernel/built-in.o: In function `ptrace_sethbpregs':
/home/stefan/build/kernels/one_plus_one/arch/arm/kernel/ptrace.c:551:
undefined reference to `__aeabi_memcpy8'
arch/arm/kernel/built-in.o: In function `gpr_set':
/home/stefan/build/kernels/one_plus_one/arch/arm/kernel/ptrace.c:610:
undefined reference to `__aeabi_memcpy4'
arch/arm/kernel/built-in.o: In function `vfp_set':
/home/stefan/build/kernels/one_plus_one/arch/arm/kernel/ptrace.c:710:
undefined reference to `__aeabi_memcpy8'
and
__aeabi_memclr
__aeabi_memclr4
__aeabi_memclr8
http://llvm.org/docs/GettingStarted.html#requirements
Followed steps till step 8
Than i applied your patch and compiled clang in release mode.
Than i compiled ther kernel with my build command
make ARCH=arm
CROSS_COMPILE=/home/stefan/build/toolchains/UBERTC-arm-eabi-4.9/bin/arm-eabi-
-l4 -j5 COMPILER_PATH=/home/stefan/build/toolchains/UBERTC-arm-eabi-4.9
GCC_TOOLCHAIN=/home/stefan/build/toolchains/UBERTC-arm-eabi-4.9
HOSTCC="/home/stefan/clang/Release/bin/clang"
CC="/home/stefan/clang/Release/bin/clang -target arm-none-eabi
-march=armv7-a -mfpu=neon -no-integrated-as -fcolor-diagnostics
-I/home/stefan/llvmlinux/toolchain/clang/head/src/clang/lib/Headers
-Wno-unused-parameter
--gcc-toolchain=/home/stefan/build/toolchains/UBERTC-arm-eabi-4.9 "
I am interested in this one
3. Add -fno-builtin-<value> to compiler flags to disable compiler from
emitting it
That is what I am doing. I have added a hidden flag on LLVM side
"-arm-memcpy". If you set "-arm-memcpy=false" it will not emit them. I will
add something like on clang as well. Probably as you suggested and some
other sources "-no-builtin-memcpy" and so.
This seems to be the best solution if that is possible. How can i do that?
Is there already a patch available?
Kind regards
Stefan Fürst
2015-08-27 13:11 GMT+02:00 Vinicius Tinti <viniciustinti at gmail.com>:
> On Tue, Aug 25, 2015 at 10:22 AM, Fürst Stefan <dieb.stefan.96 at gmail.com>
> wrote:
>
>> Hello,
>>
>> thank you very much for investigating that problem. Take your time.
>>
>
> Hi all,
>
> Please find attached the patch. I have not yet sent do LLVM because it is
> still missing the test cases for LLVM. I think it will be upstreamable by
> the weeked.
> Suggestions?
>
> Basically I am separating EABI and GNUEABI.
>
> Regards,
> Vinicius
>
>
>> Kind regards
>> Stefan Fürst
>>
>>
>>
>> 2015-08-25 12:41 GMT+02:00 Vinicius Tinti <viniciustinti at gmail.com>:
>>
>>> On Tue, Aug 25, 2015 at 6:22 AM, Fürst Stefan <dieb.stefan.96 at gmail.com>
>>> wrote:
>>>
>>>> Thank you guys for your answers,
>>>>
>>>> Where can i find that fix for eabi-arm.patch ?
>>>> Here not
>>>> http://lists.linuxfoundation.org/pipermail/llvmlinux/2015-August/thread.html#start
>>>> Was it an internal discussion ?
>>>>
>>>> -fno-builtin is already in the makefile but it does not seem to solve
>>>> my errors.
>>>>
>>>> As a hobby developer this seems to be to difficult for me because my
>>>> coding skills aren't that good yet. There must be an easier way to do that.
>>>>
>>>> "1. Implement this builtin in kernel
>>>> 2. Alter the code in question so that compiler does not generate the
>>>> call to builtin"
>>>>
>>>
>>> Hi Fûrst,
>>>
>>> I am working on fixing aeabi issue. So far what I found is that
>>> LLVM/Clang does not check the flags mention by Jan-Simon when it is
>>> generating the code. It will instead check the triple and see if it satisfy
>>> the instruction and if it does it is emited. Moreover, I am not sure of
>>> that part, the linker does not seem to recognize __aeabi_memcpy,
>>> __aeabi_memmove, __aeabi_memset.
>>>
>>> Regarding the solutions:
>>>
>>> 1. Implement this builtin in kernel
>>>
>>> I don't believe that is the best place for fixing it. It is not
>>> kernel's fault.
>>>
>>> 2. Alter the code in question so that compiler does not generate the
>>> call to builtin
>>>
>>> I don't think we have such control. If you check the below above you
>>> will se that there is no reference for memcpy and yet the compiler add it.
>>>
>>> // clang -target arm-none-gnueabihf -O2 -S -o foo.s foo.c
>>> struct my_s {
>>> unsigned long a[18];
>>> };
>>>
>>> void foo(unsigned long *t) {
>>> *(struct my_s *)t = *((struct my_s *)(1UL));
>>> }
>>>
>>> 3. Add -fno-builtin-<value> to compiler flags to disable compiler from
>>> emitting it
>>>
>>> That is what I am doing. I have added a hidden flag on LLVM side
>>> "-arm-memcpy". If you set "-arm-memcpy=false" it will not emit them. I will
>>> add something like on clang as well. Probably as you suggested and some
>>> other sources "-no-builtin-memcpy" and so.
>>>
>>> Regards,
>>> Vinicius
>>>
>>>
>>>> Kind regards,
>>>> Stefan
>>>>
>>>>
>>>>
>>>> 2015-08-25 10:31 GMT+02:00 Jan-Simon Möller <dl9pf at gmx.de>:
>>>>
>>>>> See the archives (end of thread "Ugly test fix for eabi-arm.patch") ,
>>>>> we just
>>>>> in the last 2 weeks discussed the case that LLVM/clang is wrongly
>>>>> adding the
>>>>> references for these and not
>>>>> obeys the -nostdic / -freestanding flags passed by the kernel's
>>>>> makefiles.
>>>>>
>>>>> --
>>>>>
>>>>> Dipl.-Ing.
>>>>> Jan-Simon Möller
>>>>>
>>>>> jansimon.moeller at gmx.de
>>>>> On Monday 24 August 2015 23:58:35 Khem Raj wrote:
>>>>> > > On Aug 24, 2015, at 6:14 AM, Fürst Stefan <
>>>>> dieb.stefan.96 at gmail.com>
>>>>> > > wrote:
>>>>> > >
>>>>> > > drivers/built-in.o: In function `__video_do_ioctl':
>>>>> > >
>>>>> /home/stefan/llvmlinux/targets/nexus5/src/android_kernel_nexus5/drivers/me
>>>>> > > dia/video/v4l2-ioctl.c:1604: undefined reference to
>>>>> `__aeabi_memclr4'
>>>>> > > make[1]: *** [.tmp_vmlinux1] Error 1
>>>>> > > make: *** [sub-make] Error 2
>>>>> >
>>>>> > This means that compiler is finding a place where it can rely on
>>>>> builtins
>>>>> > function implemented in compiler runtime which is compiler-rt or
>>>>> libgcc
>>>>> > depending upon which runtime you use. if it was a user application,
>>>>> then
>>>>> > simply linking with compiler-rt would have been sufficient but in
>>>>> kernel it
>>>>> > does not require any C runtime and whatever is needed is implemented
>>>>> in
>>>>> > kernel itself. So kernel has a small helper library which implements
>>>>> some
>>>>> > of these builtins, you have two options,
>>>>> >
>>>>> > 1. Implement this builtin in kernel
>>>>> > 2. Alter the code in question so that compiler does not generate the
>>>>> call to
>>>>> > builtin 3. Add -fno-builtin-<value> to compiler flags to disable
>>>>> compiler
>>>>> > from emitting it
>>>>> >
>>>>> > Thanks
>>>>> > -Khem
>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> LLVMLinux mailing list
>>>> LLVMLinux at lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/llvmlinux
>>>>
>>>
>>>
>>>
>>> --
>>> Simplicity is the ultimate sophistication
>>>
>>
>>
>
>
> --
> Simplicity is the ultimate sophistication
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/llvmlinux/attachments/20150828/332b1414/attachment.html>
More information about the LLVMLinux
mailing list