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

Wed Oct 2 14:50:16 PDT 2019

jyknight added a comment.

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

> In D67867#1691962 <https://reviews.llvm.org/D67867#1691962>, @jyknight wrote:
>
> > 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.)
>
>
> This approach is fairly general can be adopted with the existing setup as well. In fact, I can image that irrespective of the approach we take, we will end up with patterns like this.

Yes. This is totally separate from whether to use objcopy or not. I'm sorry the two concerns were merged into one comment thread.

> I agree that, "post-processing using objcopy" does sound complex as it kind of gives a feel of a complex binary surgery. But, what the current proposal is doing is to just add an alias symbol using objcopy. That is neither invasive, nor complex as "post-processing using objcopy" sounds. Moreover, as I have said earlier, developers do not need to deal with objcopy on a regular basis as it is hidden behind a build rule.

I continue to disagree that that's at all a good trade-off, but since we're only going around in circles now, I'll drop it in the name of progress.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67867