[LLVMdev] About Compiler-RT

[Chao Yan]

I had the exact same problem 3 weeks ago. The answer is yes. You need to
compile the libcompiler_rt and replace the libgcc. I'm still working on
cross-compile the compiler_rt, some problems are still not solved. In fact
there is precompiled libcompiler_rt.a file from ellcc project. Check "
ellcc.org". Hope it helps :)

Cheers,
Chao

2015-03-30 8:05 GMT-05:00 Renato Golin <renato.golin at linaro.org>:

> On 30 March 2015 at 13:37,  <qiuw at ichaier.com> wrote:
> > I used Clang to compile an ARM-v6m project. The runtime library is from
> GNU-ARM. But as I used 'memcpy' function, an error 'undefined reference to
> `__aeabi_memcpy' was emitted by linker. Does it mean that I must use LLVM
> compiler-RT instead?
>
> Hi Steven,
>
> This could be this known issue:
> https://llvm.org/bugs/show_bug.cgi?id=11326 and it affected the Linux
> kernel and Android in slightly different ways.
>
> The problem here is that Clang inadvertently changes "mem*" to
> "__aeabi_mem*" because you're compiling to ARM on EABI mode, which
> also encompass GNUEABI, which maybe it shouldn't, but there isn't a
> simple answer to this problem.
>
> In the kernel, the issue is that they don't use any libc, so they
> provide their own implementations, which don't have __aeabi_ names.
> The solution was to create an alias.
>
> In Android, the issue is that bionic (a libc complement) doesn't
> implement mem*, and has a link from mem* to __aeabi_mem*. When Clang
> does the same change on the code, it ends up with __aeabi_mem* calling
> __aeabi_mem* and of course, fails at run time. The solution is to
> create an asm file with the aliases, so that Clang doesn't do the
> switch on its own.
>
> Both solutions are ugly, but even when using the -fno-builtins option
> (that suppress the change to __aeabi and others), the end result was
> not good enough (I can't remember the specifics).
>
> In your case, I assume you're using glibc, which for ARM, should have
> __aeabi_memcpy, so I'm not sure why you can't see them. Can you give
> us more details on what the issue is, and if it is one of the above,
> maybe you should complement the bug report with more info. We'll have
> to fix that one properly one day. :)
>
> cheers,
> --renato
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150330/a1353fa4/attachment.html>