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

[Eli Friedman via Phabricator via llvm-commits]

efriedma 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?

Oh, wait, I am missing something: you're installing a symlink, and dlopen determines whether a shared library is the same based on inode, not the path.  So I guess this works out in its current form.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106703