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

[James Y Knight via Phabricator via llvm-commits]

jyknight added a comment.

In D67867#1691597 <https://reviews.llvm.org/D67867#1691597>, @sivachandra wrote:

> 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.


Correct, my suggestion above was only to reduce the complexity.

However, back to the weak-alias question -- I have a different suggestion for solving that.

The issue really only exists when you refer to object files across standards layers -- e.g., using an object file that exposes the POSIX symbol "open" from an object file implementing ISO C. If you make sure to always strictly-layer the libc, so that ISO C-implementing object files don't use any POSIX-exporting object files, and so on, you won't need to mark anything weak. For the example of "open", you'd have an internal implementation of `open` in its own file, only exposing libc-internal symbols. Then `fopen` (ISO C) can use that safely, without dragging in a definition of the symbol `open`. Separately, the implementation of `open` (POSIX) can be defined in its own file, also based on the internal open.)

> 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.

Sort of... At the source level, you can keep using namespaces as usual -- you don't need to move the function to the global namespace. E.g., given

  namespace __llvm_libc {
  extern "C" __llvm_libc_strcat(...) {
    ...
  }
  }

the `__llvm_libc_strcat` function is within the namespace `__llvm_libc`, as far as C++ name-resolution semantics are concerned. It's only at a lower level, in the object-file linkage semantics, that it is "as if" it was in the global namespace -- the function has been given the symbol name `__llvm_libc_strcat` instead of a C++ namespace-mangled name.

> 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.

I do think it's both complicated and confusing to have build rules invoking objcopy to post-process `.o` files after compilation. If that was //necessary//, it'd be one thing, but since it's not, I'd say the additional complexity is not justified.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67867