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

Vinicius Tinti viniciustinti at gmail.com
Thu Aug 27 11:11:34 UTC 2015


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/llvmlinux/attachments/20150827/6d2d19ba/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-ARM-Separate-RTLIB-for-EABI-and-GNUEABI.patch
Type: text/x-diff
Size: 6582 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/llvmlinux/attachments/20150827/6d2d19ba/attachment-0001.bin>


More information about the LLVMLinux mailing list