[cmake] Slight fix ups to make robust to the full range of GNUInstallDirsSee https://cmake.org/cmake/help/v3.14/module/GNUInstallDirs.html#result-variables for `CMAKE_INSTALL_FULL_*`Reviewed By:
[cmake] Slight fix ups to make robust to the full range of GNUInstallDirsSee https://cmake.org/cmake/help/v3.14/module/GNUInstallDirs.html#result-variables for `CMAKE_INSTALL_FULL_*`Reviewed By: sebastian-neDifferential Revision: https://reviews.llvm.org/D130545
show more ...
[llvm-libgcc] initial commitNote: 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 bechal
[llvm-libgcc] initial commitNote: 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 bechallenging since libgcc_s.so is a required dependency in the [Linuxstandard base][5]. Some software is transitively dependent on libgccbecause glibc makes hardcoded calls to functions in libgcc_s. For example,the function `__GI___backtrace` eventually makes its way to a [hardcodeddlopen to libgcc_s' _Unwind_Backtrace][1]. Since libgcc_{eh.a,s.so} andlibunwind have the same ABI, but different implementations, the twolibraries end up [cross-talking, which ultimately results in asegfault][2].To solve this problem, libunwind needs to build a “libgcc”. That is, linkthe necessary functions from compiler-rt and libunwind into an archiveand shared object that advertise themselves as `libgcc.a`, `libgcc_eh.a`,and `libgcc_s.so`, so that glibc’s baked calls are diverted to thecorrect objects in memory. Fortunately for us, compiler-rt and libunwinduse the same ABI as the libgcc family, so the problem is solvable at thellvm-project configuration level: no program source needs to be edited.Thus, the end result is for a user to configure their LLVM build with aflag that indicates they want to archive compiler-rt/unwind as libgcc.We achieve this by compiling libunwind with all the symbols necessaryfor compiler-rt to emulate the libgcc family, and then generate symlinksnamed for our "libgcc" that point to their corresponding libunwindcounterparts.We alternatively considered patching glibc so that the source doesn'tdirectly refer to libgcc, but rather _defaults_ to libgcc, so that asystem preferring compiler-rt/libunwind can point to these librariesat the config stage instead. Even if we modified the Linux standardbase, this alternative won't work because binaries that are built usinglibgcc will still end up having crosstalk between the differingimplementations.This problem has been solved in this manner for [FreeBSD][3], and thisCL has been tested against [Chrome OS][4].[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_5.0.0/LSB-Core-generic/LSB-Core-generic/libgcc-s.htmlDifferential Revision: https://reviews.llvm.org/D108416