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

[Christopher Di Bella via Phabricator via llvm-commits]

cjdb added a comment.

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

> In D106703#2901586 <https://reviews.llvm.org/D106703#2901586>, @cjdb wrote:
>
>> In D106703#2901475 <https://reviews.llvm.org/D106703#2901475>, @efriedma wrote:
>>
>>> 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.)
>>
>> (1) isn't interesting, and I think (3) is a non-starter in this case. (2) sounds to me like you're suggesting libunwind.so be a shell that points to true libgcc_s.so, which is the opposite of this patch. Could you please clarify what you mean here?
>> If a vendor builds libunwind using `-DLIBUNWIND_SYNTH_LIBGCC=On`, then that means they want libunwind to be the unwinder and there is some unfortunate circumstance that is requiring libunwind.so to masquerade as libgcc_s.so.
>
> Well, I suppose there is option (4), which is "libgcc_s.so entry points forward to libunwind.so".
>
> What this patch implements, as far as I can tell, is "There are two copies of libunwind in the process, one named libunwind.so, and one named libgcc_s.so.  If we're lucky, everything works."  Unless I'm missing something?

I don't see why there would ever be two copies of libunwind. libgcc_s.so is a symlink to libunwind.so when installed with `LIBUNWIND_SYNTH_LIBGCC=On`, so an attempt to load libgcc_s.so would mean attempting to reload the original shared object. Having said that, processes needn't explicitly link with libunwind when their system vends using this setup because libgcc_s.so is libunwind.so, and so even if my understanding about how shared objects are loaded is wrong, the problem should be avoided nonetheless.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106703