llvm dev - Mar 2015 - [LLVMdev] About Compiler-RT

Hi, all

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?

Thanks a lot.

--------------
Steven
***************************** Legal Disclaimer *****************************
"This email may contain confidential and privileged material for the sole
use of the intended recipient. Any unauthorized review, use or distribution
by others is strictly prohibited. If you have received the message in error,
please advise the sender by reply email and delete the message. Thank you."

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

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>