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

[Fürst Stefan]

Hello,

thank you very much for investigating that problem. Take your time.

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/llvmlinux/attachments/20150825/338ec14b/attachment.html>