Note: the term "libgcc" refers to the all of libgcc.a, libgcc_eh.a,
Enabling libunwind as a replacement for libgcc on Linux has proven to be challenging since libgcc_s.so is a required dependency in the Linux standard base. Some software is transitively dependent on libgcc because glibc makes hardcoded calls to functions in libgcc_s. For example, the function __GI___backtrace eventually makes its way to a hardcoded dlopen to libgcc_s' _Unwind_Backtrace. Since libgcc and libunwind have the same ABI, but different implementations, the two libraries end up cross-talking, which ultimately results in a segfault.
To solve this problem, libunwind needs to build a “libgcc” that is, link the necessary functions from compiler-rt and libunwind into an archive and shared object that advertise themselves as libgcc.a, libgcc_eh.a, and libgcc_s.so, so that glibc’s baked calls are diverted to the correct objects in memory. Fortunately for us, compiler-rt and libunwind use the same ABI as the libgcc family, so the problem is solvable at the llvm-project configuration level: no program source needs to be edited. Thus, the end result is for a user to configure their LLVM build with a flag that indicates they want to archive compiler-rt/unwind as libgcc. We achieve this by compiling libunwind with all the symbols necessary for compiler-rt to emulate the libgcc family, and then generate symlinks named for our "libgcc" that point to their corresponding libunwind counterparts.
We alternatively considered patching glibc so that the source doesn't directly refer to libgcc, but rather _defaults_ to libgcc, so that a system preferring compiler-rt/libunwind can point to these libraries at the config stage instead. Even if we modified the Linux standard base, this alternative won't work because binaries that are built using libgcc will still end up having crosstalk between the differing implementations.
This has a dependency on a compiler-rt-aware compiler.