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

Fürst Stefan dieb.stefan.96 at gmail.com
Mon Aug 31 14:55:59 UTC 2015


Thanks you guys it compiles fine now. I just found the necessary patch
there:
git clone http://git.linuxfoundation.org/llvmlinux.git
https://raw.githubusercontent.com/DerRomtester/android_kernel_oneplus_msm8974/61933df5fa0055e8945d4100c79caa5fe69a53b8/arch/arm/lib/eabi.c

Here is my git if you are interested in.
https://github.com/DerRomtester/android_kernel_oneplus_msm8974/commits/cm-12.1-caf

Sadly my android kernel does not boot at all. I must investigate that. Is
there something special i need to observe for arm (wrong target, board
specific patches for msm)?

Kind regards
Stefan

2015-08-30 13:44 GMT+02:00 Fürst Stefan <dieb.stefan.96 at gmail.com>:

> Hello,
>
> i just cloned
> git clone http://git.linuxfoundation.org/llvmlinux.git
>
> And i found in the target/msm folder the right patch for that.
> in the old eabi.c file these functions were missing. Thats why i got these
> errors. We just need that updated eabi.c file.
>
> +void __aeabi_memcpy4(void *dest, const void *src, size_t n)
> +{
> +       (void)memcpy(dest, src, n);
> +}
> +EXPORT_SYMBOL(__aeabi_memcpy4);
> +
> +void __aeabi_memcpy8(void *dest, const void *src, size_t n)
> +{
> +       (void)memcpy(dest, src, n);
> +}
> +EXPORT_SYMBOL(__aeabi_memcpy8);
> +
>  void __aeabi_memmove(void *dest, const void *src, size_t n)
>  {
>         (void)memmove(dest, src, n);
> @@ -26,3 +38,9 @@ void __aeabi_memset(void *s, size_t n, int c)
>         (void)memset(s, c, n);
>  }
>  EXPORT_SYMBOL(__aeabi_memset);
> +
> +void __aeabi_memclr8(void *s, size_t n)
> +{
> +       (void)memset(s, 0, n);
> +}
> +EXPORT_SYMBOL(__aeabi_memclr8);
>
> but i still get this errors
> "undefined reference to `__aeabi_memclr4'"
>
> Is this the right function for that ? I just want to be sure that i dont
> add bullshit.
>
> void __aeabi_memclr4(void *s, size_t n)
> {
>     (void)memset(s, 0, n);
> }
> EXPORT_SYMBOL(__aeabi_memclr4);
>
>
> Kind regards
> Stefan Fürst
>
>
>
>
>
> 2015-08-29 20:53 GMT+02:00 Behan Webster <behanw at converseincode.com>:
>
>> 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/20150831/8e2c9b48/attachment-0001.html>


More information about the LLVMLinux mailing list