[llvmlinux] Compilation errors android msm-caf-nexus5 and oneplus one

Behan Webster behanw at converseincode.com
Sat Aug 29 18:53:41 UTC 2015


Short term there is a aeabi patch in the llvmlinux arch/arm/patches dir which defines these symbols as a work around.

Behan

Sent from my Mobile Computer which is also a phone

> On Aug 28, 2015, at 9:14 AM, Fürst Stefan <dieb.stefan.96 at gmail.com> wrote:
> 
> 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
> 
> _______________________________________________
> LLVMLinux mailing list
> LLVMLinux at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/llvmlinux
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/llvmlinux/attachments/20150829/d26e7084/attachment.html>


More information about the LLVMLinux mailing list