[PATCH] D67867: [libc] Add few docs and implementation of strcpy and strcat.

Siva Chandra via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Wed Oct 2 10:09:35 PDT 2019


sivachandra added a comment.

In D67867#1688779 <https://reviews.llvm.org/D67867#1688779>, @jyknight wrote:

> In D67867#1688556 <https://reviews.llvm.org/D67867#1688556>, @sivachandra wrote:
>
> > The objcopy step is required to avoid putting mangled names with the alias attribute. If there is any other way to achieve the same thing, I am open to it.
>
>
> Ah, I see! I'd suggest using extern "C" instead. There's no need for these be C++-mangled -- you can simply use a name prefix instead. E.g., if you define it as `extern "C" __llvm_libc_strcpy(...) {}` then it's trivial to make the `strcpy` alias without objcopy magic.


Yes, this solution was considered. But, it does not really solve the problem you brought up; we will still need to make the alias weak. It of course eliminates the objcopy step, but we end up with some kind of source code mismatch/inconsistency (for the lack of a better word I can think of). That is, we will have the main function in a global namespace, while the support/helper functions will live inside of a namespace. I rather prefer everything in a single LLVM-libc specific namespace. The objcopy step is neatly hidden behind a build rule, so I do not see it as being "complicated" or "confusing". Someone coming in to implement a new function just has to use the build rule and put the code in the namespace.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D67867/new/

https://reviews.llvm.org/D67867





More information about the llvm-commits mailing list