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

Fri Jul 23 16:45:39 PDT 2021

efriedma added a comment.

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?

In D106703#2901595 <https://reviews.llvm.org/D106703#2901595>, @manojgupta wrote:

>> 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.
>
> After this patch we'll no longer install true libgcc* libraries on system anymore to avoid any crosstalk issue. llvm's libunwind will be the only one present with anything libgcc*  symlinked to libunwind/compiler-rt etc. This way, we will not have any real libgcc dependencies in Chrome OS or crosstalk.

I'd rather not be in a situation where a program built with a normal production toolchain appears to work, but then randomly crashes because the unwinder clashes with libgcc.  Unless Chrome OS actually refuses to load binaries built with a normal Linux toolchain, we should ensure those binaries work.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106703