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

[Fangrui Song via Phabricator via llvm-commits]

MaskRay added a comment.

I try to play with this patch and run into problems.
I have a `-DLLVM_TARGETS_TO_BUILD=host -DLIBUNWIND_USE_COMPILER_RT=on -DLIBUNWIND_SYNTH_LIBGCC=x86_64` build at /tmp/out/custom1.
`synth_libgcc` fails:

  % ninja -C /tmp/out/custom1 synth_libgcc
  ninja: Entering directory `/tmp/out/custom1'
  [1/1] cd /tmp/out/custom1/projects/libunwind/src && /usr/bin/cmake -E create_symlink  /tmp/out/custom1/./lib/libgcc.a
  FAILED: projects/libunwind/src/CMakeFiles/synth_libgcc
  cd /tmp/out/custom1/projects/libunwind/src && /usr/bin/cmake -E create_symlink  /tmp/out/custom1/./lib/libgcc.a
  ...

`LIBUNWIND_BUILTINS_LIBRARY` is empty in my build, so my libunwind.so.1.0 doesn't have builtins symbols.
`if (LIBUNWIND_SUPPORTS_NOSTDLIBXX_FLAG OR LIBUNWIND_SUPPORTS_NODEFAULTLIBS_FLAG)` evaluates to true.

---

The intention of `LIBUNWIND_BUILTINS_LIBRARY` appears to merge libclang_rt.builtins-* and libunwind into libunwind.so.1.0.
Then a symlink libgcc_s.so.1 is provided.

But why is --version-script with some `GCC_*` version nodes used?
libclang_rt.builtins-* and libunwind lack quite a few symbols from a real libgcc_s.so.1.
Many prebuilt applications with a libgcc_s.so.1 DT_NEEDED entry can probably run with the fake libgcc_s.so.1, but many won't.

---

> libunwind/gcc_s-i386.ver
> `__dlopen`

A version script only affects defined symbols. Patterns like `__dlopen` are not defined and should be removed.

> `} Unwind_Only;`

The syntax is completed ignored in GNU ld and ld.lld. There is no dependency. Just use `};`

You can remove `global:`. It is ignored.

---

> 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.
> https://refspecs.linuxbase.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/libgcc-s.html

The latest version is 5 which is available on https://refspecs.linuxfoundation.org/lsb.shtml

---

> 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.

POSIX does not require that `pthread_cancel` unwinds the stack and executes landing pads (usually local variable destructors from -fexceptions C++ code).
glibc and FreeBSD implementations provide the feature. musl doesn't.

My opinion is that this is an unneeded feature. The landing pad execution doesn't help a lot of -fno-exceptions code anyway.

If you can patch glibc, you may just drop drop the ` __libc_dlopen (LIBGCC_S_SO);` and dlsym `_Unwind_*` code.
Then your glibc will not dlopen libgcc.so.1, and the problem will be solved.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D106703