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

Sun Sep 29 00:18:31 PDT 2019

theraven added a comment.

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

> In D67867#1686056 <https://reviews.llvm.org/D67867#1686056>, @hfinkel wrote:
>
> > Maybe everything is fine, but given this setup, does anyone see any potential problems with compiling these functions for nvptx? I'd like to eventually see a mode where we compile an appropriate subset of these functions for GPU targets -- either in bitcode form for linking with our device-side OpenMP runtime library or as a native object -- to provide a more feature-complete offloading environment.
> >
> > The one thing that caught by eye was the use of the section attribute, and I was curious what nvptx does with that. As far as I can tell, perhaps the answer is nothing.
>
>
> Then I think this scheme won't work, since the point of the sections is to enable the creation of the global symbols post-build.
>
> E.g., I think the idea is that the main implementation defines the function with C++ name `__llvm_libc::strcpy(char *, const char *)`, and places the code in the `.llvm.libc.entrypoint.strcpy` section. And then another tool comes along and iterates the llvm.libc.entrypoint sections, and adds global symbol aliases for each one.
>
> That scheme feels probably over-complex, IMO, but I don't have an concrete counter-proposal in mind.

For what it's worth, FreeBSD libc does a similar namespacing trick in C.  The internal symbols are underscore prefixed and they're exported as aliases (typically as weak aliases, to allow them to be preempted by other implementations, and to explicitly give names to callers for the preemptible and non-preemptible versions).  Making symbols preemptible isn't really possible with PE/COFF, because the linkage model has a stronger concept of where definitions come from than ELF (at least, in the absence of symbol versions in ELF).  On ELF platforms, we should support symbol versions as early as possible, because adding them later is an ABI break, even if we change no code.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67867