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

[Eli Friedman via Phabricator via llvm-commits]

efriedma added a comment.

In D106703#2901404 <https://reviews.llvm.org/D106703#2901404>, @cjdb wrote:

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

I meant that there can only be one "true" unwinder, that exposes the libgcc_s.so symbols, and it has to be named libgcc_s.so.  Having a libunwind.so installed on the same system exposing the same symbols is just confusing at best, even if it sort of works if they're the same version.

So one of the following should be true on a system with a library named libgcc_s.so:

1. libunwind.so isn't be installed on the system.
2. libunwind.so entry points forward to libgcc_s.so
3. libunwind.so exposes APIs with different names, if someone wanted to explicitly use it for some reason.  (Not sure if this is a likely use-case.)

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

If there's crosstalk between libgcc.a and libunwind.so, binaries built on systems with true libgcc.a will break on systems with libunwind.so installed as libgcc_s.so.  Messing with the names is just covering up the issue.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106703