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

[Vinicius Tinti]

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/36a676c5/attachment.html>