[llvmlinux] Compilation errors android msm-caf-nexus5 and oneplus one
Behan Webster
behanw at converseincode.com
Tue Sep 1 02:42:44 UTC 2015
That's actually our patch from our build system. :)
Like I said, you'll find it in our arch/arm/patches dir.
LOL. I wrote most of that patch.
Behan
On 08/31/15 07:55, Fürst Stefan wrote:
> 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
> <mailto: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 <mailto: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 <mailto: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 <mailto:viniciustinti at gmail.com>>:
>>
>> On Tue, Aug 25, 2015 at 10:22 AM, Fürst Stefan
>> <dieb.stefan.96 at gmail.com
>> <mailto: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
>> <mailto:viniciustinti at gmail.com>>:
>>
>> On Tue, Aug 25, 2015 at 6:22 AM, Fürst Stefan
>> <dieb.stefan.96 at gmail.com
>> <mailto: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 <mailto: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
>> <mailto: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
>> <mailto: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
>> <mailto: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
>> <mailto:LLVMLinux at lists.linuxfoundation.org>
>> https://lists.linuxfoundation.org/mailman/listinfo/llvmlinux
>
>
>
--
Behan Webster
behanw at converseincode.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/llvmlinux/attachments/20150831/9c9509a9/attachment-0001.html>
More information about the LLVMLinux
mailing list