[libc-commits] [PATCH] D69020: Illustrate a redirector using the example of round function from math.h.

[Siva Chandra via Phabricator via libc-commits]

sivachandra added a comment.

In D69020#1723979 <https://reviews.llvm.org/D69020#1723979>, @jakehehrlich wrote:

> I guess my question is more, whats the evidence that there isn't a way to avoid the two call overhead? The use case makes sense to me but my impression is that `__round_redirector` could be declared to have extern "C" linkage and then `llvm_libc::round` can be an alias for it. That gets rid of 1 layer of indirection. Getting rid of the next call seems more gross to me but I think some additional objcopy magic can be done to make `__round_redirector` an alias for `::round` then I think this would all link correctly, right?


I have probably not listed out some of the constraints clearly. One of them is this: Even with LLVM-libc redirectors used, we want  link to the system libc dynamically. This is because: 1. On most platforms, one links to the system libc dynamically, 2. If the system-libc were glibc, then we cannot unconditionally link to it statically anyway. Hence, I am not sure if we can eliminate the second call at all.

About the scheme you suggest to eliminate the function call:

Let me simplify it further. When redirectors are involved, we do not really need a `llvm_libc::round`. We can just have `extern "C" __round_redirector` and add an alias added to it using `llvm-objcopy` or put it in source. Look at this example: https://github.com/sivachandra/redirectors

The problem with this scheme is that, since the alias `round` and the aliasee `__round_redirector` both live in the same object file, linkers will end up wiring a recursive call even if `round` is a hidden symbol.

Did I misunderstand your suggestion?

> We can do this for now perhaps and then we can add a feature to llvm-objcopy called `--add-symbol-alias` that would allow adding symbol aliases like this.

If we can come up with schemes which require help from tools like llvm-objcopy (even if they have to be extended), I think that would be acceptable. In this case though, unless I have totally misunderstood your proposal, it does not seem like we can pull off without some form special treatment from the linker.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D69020