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

[Christopher Di Bella via Phabricator via libcxx-commits]

cjdb created this revision.
cjdb added reviewers: manojgupta, kristof.beyls, phosek.
Herald added subscribers: libcxx-commits, krytarowski, arichardson, mgorny, emaste.
Herald added a project: libunwind.
Herald added a reviewer: libunwind.
cjdb requested review of this revision.
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Note: the term "libgcc" refers to the all of `libgcc.a`, `libgcc_eh.a`,
and `libgcc_s.so`.

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][5]. 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][1]. Since libgcc_{eh.a,s.so} and
libunwind have the same ABI, but different implementations, the two
libraries end up [cross-talking, which ultimately results in a
segfault][2].

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 conisdered 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 problem has been solved in this manner for FreeBSD[3], and this
CL has been tested against Chrome OS[4].

This has a dependency on a compiler-rt-aware compiler.

[1]: https://github.com/bminor/glibc/blob/master/sysdeps/arm/backtrace.c#L68
[2]: https://bugs.chromium.org/p/chromium/issues/detail?id=1162190#c16
[3]: https://github.com/freebsd/freebsd-src/tree/main/lib/libgcc_s
[4]: https://chromium-review.googlesource.com/c/chromiumos/overlays/chromiumos-overlay/+/2945947
[5]: https://refspecs.linuxbase.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/libgcc-s.html


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D106703

Files:
  libunwind/CMakeLists.txt
  libunwind/cmake/config-ix.cmake
  libunwind/gcc_s-aarch64.ver
  libunwind/gcc_s-armv7a.ver
  libunwind/gcc_s-i386.ver
  libunwind/gcc_s-x86_64.ver
  libunwind/src/CMakeLists.txt

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D106703.361310.patch
Type: text/x-patch
Size: 27428 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/libcxx-commits/attachments/20210723/af289b45/attachment-0001.bin>