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

Khem Raj raj.khem at gmail.com
Fri Aug 28 19:23:15 UTC 2015


Stefan

Add -ffreestanding to CFLAGS, kernel being a bare metal should use this flag globally IMO, it might cause problems
due to altered meanings of c99 types but try it. Second option would be to add -fno-builtin globally and if that does not work
then go to specific subsystem makefile and add it there.

Thanks
-Khem

> 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 <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 <mailto:viniciustinti at gmail.com>>:
> On Tue, Aug 25, 2015 at 10:22 AM, Fürst Stefan <dieb.stefan.96 at gmail.com <mailto: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 <mailto:viniciustinti at gmail.com>>:
> On Tue, Aug 25, 2015 at 6:22 AM, Fürst Stefan <dieb.stefan.96 at gmail.com <mailto: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 <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 <mailto: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 <mailto: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 <mailto: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 <mailto:LLVMLinux at lists.linuxfoundation.org>
> https://lists.linuxfoundation.org/mailman/listinfo/llvmlinux <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/20150828/679939d8/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 204 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/llvmlinux/attachments/20150828/679939d8/attachment-0001.sig>


More information about the LLVMLinux mailing list