[libcxx-commits] [PATCH] D106703: [libunwind] adds a way to synthesise libgcc

[Christopher Di Bella via Phabricator via libcxx-commits]

cjdb added a comment.

In D106703#2901327 <https://reviews.llvm.org/D106703#2901327>, @efriedma wrote:

> If I'm understanding correctly, there are two components to this: shared libraries, and static libraries.
>
> If you have both libgcc_s.so and libunwind.so in the same process, exposing APIs with the same names, the result is confusing at best, sure.  Either we need APIs with different names, or libunwind.so needs to replace libgcc_s.so.  Ideally, we'd do both, to give users flexibility.  But if we're not going to rename the libunwind.so APIs, we shouldn't install libunwind.so at all, since it isn't usable.

The problem here isn't that the process //wants// to use both libgcc_s.so and libunwind.so, but rather that it sometimes "needs" to. glibc has a hardcoded dlopens to libgcc_s.so,  so anyone using glibc will find libgcc_s.so is inescapable even when using libunwind.so, which rules out both an API rename and replacing libgcc_s.so.

> For the static libraries, I'm not sure what problem you're trying to solve.  If someone tries to link against both sets of static libraries, that's pretty clearly user error.  And the symbols have hidden visibility, so they shouldn't interfere with other shared libraries.

This solves a different part of the crosstalk problem. While trying to migrate Chrome OS from libgcc to compiler-rt and libunwind, I observed that there was crosstalk when statically linking objects too. In this case, I believe the crosstalk is between true libgcc.a and libunwind.so.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106703