[llvmlinux] Compilation errors android msm-caf-nexus5 and oneplus one
Fürst Stefan
dieb.stefan.96 at gmail.com
Sun Aug 30 11:44:32 UTC 2015
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/20150830/9b82912f/attachment.html>
More information about the LLVMLinux
mailing list