[libunwind] adds a way to synthesise libgcc

[cjdb]

Summary

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

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

[cjdb]

rebases to reactivate CI

[efriedma]

If I'm understanding correctly, there are two components to this: shared libraries, and static libraries.

If you have both libgcc_s.so and libunwind.so in the same process, exposing APIs with the same names, the result is confusing at best, sure. Either we need APIs with different names, or libunwind.so needs to replace libgcc_s.so. Ideally, we'd do both, to give users flexibility. But if we're not going to rename the libunwind.so APIs, we shouldn't install libunwind.so at all, since it isn't usable.

For the static libraries, I'm not sure what problem you're trying to solve. If someone tries to link against both sets of static libraries, that's pretty clearly user error. And the symbols have hidden visibility, so they shouldn't interfere with other shared libraries.

[cjdb]

In D106703#2901327, @efriedma wrote:

If I'm understanding correctly, there are two components to this: shared libraries, and static libraries.

If you have both libgcc_s.so and libunwind.so in the same process, exposing APIs with the same names, the result is confusing at best, sure. Either we need APIs with different names, or libunwind.so needs to replace libgcc_s.so. Ideally, we'd do both, to give users flexibility. But if we're not going to rename the libunwind.so APIs, we shouldn't install libunwind.so at all, since it isn't usable.

The problem here isn't that the process wants to use both libgcc_s.so and libunwind.so, but rather that it sometimes "needs" to. glibc has a hardcoded dlopens to libgcc_s.so, so anyone using glibc will find libgcc_s.so is inescapable even when using libunwind.so, which rules out both an API rename and replacing libgcc_s.so.

For the static libraries, I'm not sure what problem you're trying to solve. If someone tries to link against both sets of static libraries, that's pretty clearly user error. And the symbols have hidden visibility, so they shouldn't interfere with other shared libraries.

This solves a different part of the crosstalk problem. While trying to migrate Chrome OS from libgcc to compiler-rt and libunwind, I observed that there was crosstalk when statically linking objects too. In this case, I believe the crosstalk is between true libgcc.a and libunwind.so.

[efriedma]

In D106703#2901404, @cjdb wrote:

In D106703#2901327, @efriedma wrote:

If I'm understanding correctly, there are two components to this: shared libraries, and static libraries.

If you have both libgcc_s.so and libunwind.so in the same process, exposing APIs with the same names, the result is confusing at best, sure. Either we need APIs with different names, or libunwind.so needs to replace libgcc_s.so. Ideally, we'd do both, to give users flexibility. But if we're not going to rename the libunwind.so APIs, we shouldn't install libunwind.so at all, since it isn't usable.

The problem here isn't that the process wants to use both libgcc_s.so and libunwind.so, but rather that it sometimes "needs" to. glibc has a hardcoded dlopens to libgcc_s.so, so anyone using glibc will find libgcc_s.so is inescapable even when using libunwind.so, which rules out both an API rename and replacing libgcc_s.so.

I meant that there can only be one "true" unwinder, that exposes the libgcc_s.so symbols, and it has to be named libgcc_s.so. Having a libunwind.so installed on the same system exposing the same symbols is just confusing at best, even if it sort of works if they're the same version.

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

For the static libraries, I'm not sure what problem you're trying to solve. If someone tries to link against both sets of static libraries, that's pretty clearly user error. And the symbols have hidden visibility, so they shouldn't interfere with other shared libraries.

This solves a different part of the crosstalk problem. While trying to migrate Chrome OS from libgcc to compiler-rt and libunwind, I observed that there was crosstalk when statically linking objects too. In this case, I believe the crosstalk is between true libgcc.a and libunwind.so.

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.

[cjdb]

In D106703#2901475, @efriedma wrote:

In D106703#2901404, @cjdb wrote:

In D106703#2901327, @efriedma wrote:

If I'm understanding correctly, there are two components to this: shared libraries, and static libraries.

If you have both libgcc_s.so and libunwind.so in the same process, exposing APIs with the same names, the result is confusing at best, sure. Either we need APIs with different names, or libunwind.so needs to replace libgcc_s.so. Ideally, we'd do both, to give users flexibility. But if we're not going to rename the libunwind.so APIs, we shouldn't install libunwind.so at all, since it isn't usable.

The problem here isn't that the process wants to use both libgcc_s.so and libunwind.so, but rather that it sometimes "needs" to. glibc has a hardcoded dlopens to libgcc_s.so, so anyone using glibc will find libgcc_s.so is inescapable even when using libunwind.so, which rules out both an API rename and replacing libgcc_s.so.

I meant that there can only be one "true" unwinder, that exposes the libgcc_s.so symbols, and it has to be named libgcc_s.so. Having a libunwind.so installed on the same system exposing the same symbols is just confusing at best, even if it sort of works if they're the same version.

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.

For the static libraries, I'm not sure what problem you're trying to solve. If someone tries to link against both sets of static libraries, that's pretty clearly user error. And the symbols have hidden visibility, so they shouldn't interfere with other shared libraries.

This solves a different part of the crosstalk problem. While trying to migrate Chrome OS from libgcc to compiler-rt and libunwind, I observed that there was crosstalk when statically linking objects too. In this case, I believe the crosstalk is between true libgcc.a and libunwind.so.

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.

Some systems (e.g. Chrome OS) don't have this problem because true libgcc.a isn't available.

[manojgupta]

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.

[efriedma]

In D106703#2901586, @cjdb wrote:

In 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, @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.

[cjdb]

In D106703#2901797, @efriedma wrote:

In D106703#2901586, @cjdb wrote:

In 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?

I don't see why there would ever be two copies of libunwind. libgcc_s.so is a symlink to libunwind.so when installed with LIBUNWIND_SYNTH_LIBGCC=On, so an attempt to load libgcc_s.so would mean attempting to reload the original shared object. Having said that, processes needn't explicitly link with libunwind when their system vends using this setup because libgcc_s.so is libunwind.so, and so even if my understanding about how shared objects are loaded is wrong, the problem should be avoided nonetheless.

[efriedma]

In D106703#2901797, @efriedma wrote:

In D106703#2901586, @cjdb wrote:

In 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?

Oh, wait, I am missing something: you're installing a symlink, and dlopen determines whether a shared library is the same based on inode, not the path. So I guess this works out in its current form.

[efriedma]

In D106703#2901842, @efriedma wrote:

Oh, wait, I am missing something: you're installing a symlink, and dlopen determines whether a shared library is the same based on inode, not the path. So I guess this works out in its current form.

Err, no, that's not right; the CMake steps in the patch create a symlink in the build directory, then install() copies the whole library to the install directory, so it isn't symlinked anymore.

In D106703#2901831, @cjdb wrote:

Having said that, processes needn't explicitly link with libunwind when their system vends using this setup because libgcc_s.so is libunwind.so, and so even if my understanding about how shared objects are loaded is wrong, the problem should be avoided nonetheless.

If nothing actually links to the library named libunwind.so, why install a library with that name?

[manojgupta]

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.

Yes, Chrome OS actually requires compiling everything using the Chrome OS toolchain/SDK. Using binaries built using any other toolchain or Linux distros is not allowed so we are mostly fine in this regard.

[efriedma]

In D106703#2901955, @manojgupta wrote:

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.

Yes, Chrome OS actually requires compiling everything using the Chrome OS toolchain/SDK. Using binaries built using any other toolchain or Linux distros is not allowed so we are mostly fine in this regard.

Okay.

In that case, please make sure the CMake option explicitly notes this compatibility constraint.

[cjdb]

In D106703#2901851, @efriedma wrote:

In D106703#2901842, @efriedma wrote:

Oh, wait, I am missing something: you're installing a symlink, and dlopen determines whether a shared library is the same based on inode, not the path. So I guess this works out in its current form.

Err, no, that's not right; the CMake steps in the patch create a symlink in the build directory, then install() copies the whole library to the install directory, so it isn't symlinked anymore.

My Chrome OS build shows this.

$ ls -l /usr/lib64/libgcc_s*
lrwxrwxrwx. 1 root root 12 Jul 21 23:31 /usr/lib64/libgcc_s.so -> libunwind.so
lrwxrwxrwx. 1 root root 14 Jul 21 23:31 /usr/lib64/libgcc_s.so.1 -> libunwind.so.1

Those look like symlinks to me?

In D106703#2901831, @cjdb wrote:

Having said that, processes needn't explicitly link with libunwind when their system vends using this setup because libgcc_s.so is libunwind.so, and so even if my understanding about how shared objects are loaded is wrong, the problem should be avoided nonetheless.

If nothing actually links to the library named libunwind.so, why install a library with that name?

Two reasons:

1. It could possibly break projects that do opt into using libunwind and the library isn't present.
2. It'd be weird for libunwind to install libgcc* on its lonesome.

[MaskRay]

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.

The reliable way is to rebuild these programs, instead of assuming libunwind+libclang_rt.builtins can provide the compatibility.

If such prebuilt programs are relatively few, just drop their symbol versioning (.gnu.version* sections and DT_GNU_VER* dynamic tags)

cp in.so out.so
r2 -wqc '/x feffff6f @ section..dynamic; w0 8 @ hit0_0' out.so
llvm-objcopy -R .gnu.version out.so

---

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

[cjdb]

updates CMake option description and adds documentation for how to use this feature

[cjdb]

In D106703#2902097, @MaskRay wrote:

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.

LIBUNWIND_BUILTINS_LIBRARY may require you to do a two stage build but this is related to the pre-existing LIBUNWIND_USE_COMPILER_RT option, not because of any changes in this patch. Stage1: Build clang and compiler-rt. Stage 2: Use the freshly-built clang to compile libunwind.

I’ve added a manual that explains how to build using this feature in the latest revision. PTAL and try again.

---

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.

Our experience with testing this on the whole of Chrome OS suggests that what’s available is sufficient for our use case.

The reliable way is to rebuild these programs, instead of assuming libunwind+libclang_rt.builtins can provide the compatibility.

We build (almost) everything in Chrome OS from source and have very few vendor binaries so compatibility is not a huge problem for us.

This is mostly a patch to assist distros that can manage their libraries (e.g. Chrome OS, FreeBSD, etc.); it’s not useful for average LLVM users to build for themselves. This feature is opt-in: anyone wanting to use this patch must’ve figured out their compatibility requirements beforehand.

If such prebuilt programs are relatively few, just drop their symbol versioning (.gnu.version* sections and DT_GNU_VER* dynamic tags)

cp in.so out.so
r2 -wqc '/x feffff6f @ section..dynamic; w0 8 @ hit0_0' out.so
llvm-objcopy -R .gnu.version out.so

---

libunwind/gcc_s-i386.ver
__dlopen

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

Thanks for noticing, I’ll audit the version script again to remove symbols not provided by compiler-rt. I’ll need a day or so to look into this as I’ll be testing this on Chrome OS CQ before pushing here.

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

Thanks for noting this. My understanding of the ld documentation suggests that we should beep both of these. I’ll play with stuff and report back, but this will require at least 48h.

---

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

Thanks, but LSB 5 still has the same requirements.

---

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

The POSIX spec isn’t relevant for applications that are already dependent on glibc behaviour. The commit message shows an example calling the backtrace function, which isn’t pthread-related. LSB requirement also makes it a non-starter for a glibc patch, and use of -static-libgcc will still require a dlopen.

Please keep in mind that this patch isn’t for mainstream developers, but for distro managers who are looking to completely replace libgcc in their system.

[cjdb]

• rebases since it's been a while
• revises version scripts so that they're exactly ((compiler-rt-symbols ∪ llvm-libunwind-symbols) ∩ libgcc_s-symbols)
• removes global: and dependency labels

@MaskRay I think I've now addressed all your feedback.

[compnerd]

I think that this should be moved into a subdirectory in llvm/runtimes that @beanz has setup already. It is pulling pieces from the compiler-rt builtins and libunwind and is not really isolated into one or the other. Additionally, this really does deserve a warning that this requires careful setup and can cause issues.

[MaskRay]

(I have implemented some missing parts of ld.lld symbol versioning recently: D107235 D107234 D107535. This ensures if we ever have a non-default version symbol, the version script should be good.)

My understanding of this patch:
Synthesize a symbol versioned libgcc_s.so.1 from libclang_rt.builtins-*.a and libunwind.a.

Many applications built with GCC libgcc_s.so.1 can run with their libgcc_s.so.1 runtime replaced with the synthesized one.

I may conjecture people's concern with the patch:

• maintenance burden. This is a new build way most users don't exercise (for now). Is unintentionally breaking ChromeOS builds ground for reverting their patches, assuming their patches are otherwise good.
• does this script fit in libunwind/ or should it sit somewhere else?
• do the set of symbols enable good code sharing? Many platforms have their customization. Personally I think the code sharing may be less than what people might feel about

I am chatting with a few others on thoughts:)

---

Having a version script for every architecture is difficult to maintain.
For a new symbol, a contributor needs to figure out every version map.

I think two better alternatives:

• use C preprocessed version script file with conditional macros like #ifdef __x86_64__.
• concatenate the base version script with an arch-specific version script.

Most symbols are shared anyway.

libunwind/gcc_s-aarch64.ver

147

This just makes the symbol emutls_init@@Unversioned. It doesn't mean unversioned.

You can just omit the symbols.

local: *; will localize these unversioned symbols, so local: *; cannot be used.

[MaskRay]

libunwind/gcc_s-armv7a.ver

105

You may place more symbols on one line if that can improve readability.

Perhaps some comments as well.

[beanz]

I agree with @compnerd that this would make more sense as a feature of the runtimes build directory since it is bringing together pieces from multiple runtimes (libunwind & compiler-rt).

libunwind/CMakeLists.txt

82

I'm confused about this option. Is it a bool as documented, or a string as implemented? Please clarify.

[MaskRay]

Personally I think the code sharing this patch may enable is less than what people may feel about.
Different platforms may not use the same set of source files.
But I want authoritative opinions from FreeBSD (@dim):)

[cjdb]

We considered an approach to do this in libunwind but reviewers opinion was to make libgcc its own separate build. After some back and forth, we agreed that this would probably be the best path forward. This effort is now being tracked by D108416.

libunwind/CMakeLists.txt

 cmake_dependent_option(LIBUNWIND_INSTALL_STATIC_LIBRARY
   "Install the static libunwind library." ON
   "LIBUNWIND_ENABLE_STATIC;LIBUNWIND_INSTALL_LIBRARY" OFF)
 cmake_dependent_option(LIBUNWIND_INSTALL_SHARED_LIBRARY
   "Install the shared libunwind library." ON
   "LIBUNWIND_ENABLE_SHARED;LIBUNWIND_INSTALL_LIBRARY" OFF)
 set(LIBUNWIND_TARGET_TRIPLE "${LLVM_DEFAULT_TARGET_TRIPLE}" CACHE STRING "Target triple for cross compiling.")
 set(LIBUNWIND_GCC_TOOLCHAIN "" CACHE PATH "GCC toolchain for cross compiling.")
+set(LIBUNWIND_SYNTH_LIBGCC "" CACHE
+    STRING "Synthesises symbolic links for the libgcc family of libraries that point to libunwind and compiler-rt. This flag is only useful for distribution managers wanting to replace libgcc with libunwind, and should not be used by mainstream LLVM consumers. Requires LIBUNWIND_USE_COMPILER_RT=ON.")
 set(LIBUNWIND_SYSROOT "" CACHE PATH "Sysroot for cross compiling.")
 set(LIBUNWIND_TEST_LINKER_FLAGS "" CACHE STRING
     "Additional linker flags for test programs.")
 set(LIBUNWIND_TEST_COMPILER_FLAGS "" CACHE STRING
     "Additional compiler flags for test programs.")
 set(LIBUNWIND_TEST_CONFIG "${CMAKE_CURRENT_SOURCE_DIR}/test/lit.site.cfg.in" CACHE STRING
     "The Lit testing configuration to use when running the tests.")
 set(LIBUNWIND_TEST_PARAMS "" CACHE STRING
if(LIBUNWIND_SYSROOT)
   add_target_flags_if_supported("--sysroot=${LIBUNWIND_SYSROOT}")
 elseif(CMAKE_SYSROOT)
   set(LIBUNWIND_SYSROOT "${CMAKE_SYSROOT}")
 endif()
 
 # Configure compiler.
 include(config-ix)
 
+if (LIBUNWIND_SYNTH_LIBGCC AND NOT LIBUNWIND_USE_COMPILER_RT)
+  message(SEND_ERROR "LIBUNWIND_SYNTH_LIBGCC and LIBUNWIND_USE_COMPILER_RT must have the same value (got LIBUNWIND_SYNTH_LIBGCC=${LIBUNWIND_SYNTH_LIBGCC} and LIBUNWIND_USE_COMPILER_RT=${LIBUNWIND_USE_COMPILER_RT}).")
+endif()
+
 if (LIBUNWIND_USE_COMPILER_RT AND NOT LIBUNWIND_HAS_NODEFAULTLIBS_FLAG)
   list(APPEND LIBUNWIND_LINK_FLAGS "-rtlib=compiler-rt")
 endif()
 
 add_compile_flags_if_supported(-Werror=return-type)
 
 # Get warning flags
 add_compile_flags_if_supported(-W)

libunwind/cmake/config-ix.cmake

 include(CMakePushCheckState)
 include(CheckCCompilerFlag)
 include(CheckCXXCompilerFlag)
 include(CheckLibraryExists)
 include(CheckSymbolExists)
 include(CheckCSourceCompiles)
 
 check_library_exists(c fopen "" LIBUNWIND_HAS_C_LIB)
+check_library_exists(m log "" LIBUNWIND_HAS_M_LIB)
 
 if (NOT LIBUNWIND_USE_COMPILER_RT)
   if (ANDROID)
     check_library_exists(gcc __gcc_personality_v0 "" LIBUNWIND_HAS_GCC_LIB)
   else ()
     check_library_exists(gcc_s __gcc_personality_v0 "" LIBUNWIND_HAS_GCC_S_LIB)
     check_library_exists(gcc __absvdi2 "" LIBUNWIND_HAS_GCC_LIB)
   endif ()

libunwind/docs/BuildingLibunwind.rst

.. option:: LIBUNWIND_SYSROOT
   Sysroot for cross compiling
 
 .. option:: LIBUNWIND_INSTALL_LIBRARY_DIR:PATH
 
   **Default**: ``lib${LIBUNWIND_LIBDIR_SUFFIX}``
 
   Path where built libunwind libraries should be installed. If a relative path,
   relative to ``CMAKE_INSTALL_PREFIX``.
+
+.. option:: LIBUNWIND_SYNTH_LIBGCC:BOOL
+
+  Synthesises symbolic links for the libgcc family of libraries that point to
+  libunwind and compiler-rt. This flag is only useful for distribution managers
+  wanting to replace libgcc with libunwind, and should not be used by mainstream
+  LLVM consumers. Requires ``LIBUNWIND_USE_COMPILER_RT=ON``.
+
+  **Default**: ``OFF``
+
+.. _Building libunwind with ``LIBUNWIND_SYNTH_LIBGCC``
+
+Building libunwind with `LIBUNWIND_SYNTH_LIBGCC`
+================================================
+
+**Note that these instructions assume a Linux and bash-friendly environment.
+YMMV if you’re on a non Linux-based platform.**
+
+Building libunwind with ``LIBUNWIND_SYNTH_LIBGCC`` requires a compiler that
+supports compiler-rt when its builtin symbols are exported. This usually means
+having two build trees instead of the usual one.
+
+.. code-block:: bash
+
+  # Assumes $(PWD) is /path/to/llvm-project
+  $ mkdir -p build
+  $ cd build
+
+.. _Building Clang
+
+Building Clang
+--------------
+
+The first build tree is a mostly conventional build tree and gets you a Clang
+build with these compiler-rt symbols exposed.
+
+.. code-block:: bash
+  # Assumes $(PWD) is /path/to/llvm-project
+  $ mkdir -p build/clang
+  $ cd build/clang
+  $ cmake -GNinja ../../llvm                     \
+      -DLLVM_ENABLE_PROJECTS='clang;compiler-rt' \
+      -DCOMPILER_RT_BUILTINS_HIDE_SYMBOLS=OFF
+  $ ninja
+
+.. _Building libunwind
+
+Building libunwind
+------------------
+
+Now that we have a copy of compiler-rt with its builtin symbols exported, we can
+go about building libunwind in a second tree. We synthesise libgcc for x86_64 in
+the example below, but it’s possible to do it for any architecture that has a
+`version script`_ in the top-level directory of libunwind (presently i686,
+x86_64, armv7, and aarch64).
+
+.. _version script: https://sourceware.org/binutils/docs/ld/VERSION.html
+
+.. code-block:: bash
+
+  # Assumes $(PWD) is /path/to/llvm-project
+  $ mkdir -p build/libunwind
+  $ cd build/libunwind
+  $ cmake -GNinja ../../libunwind \
+      -DCMAKE_C_COMPILER=/path/to/llvm-project/build/clang/bin/clang     \
+      -DCMAKE_CXX_COMPILER=/path/to/llvm-project/build/clang/bin/clang++ \
+      -DLIBUNWIND_SYNTH_LIBGCC=x86_64                                    \
+      -DLIBUNWIND_USE_COMPILER_RT=On                                     \
+      -DLIBUNWIND_HAS_COMMENT_LIB_PRAGMA=Off                             \
+      -DLIBUNWIND_HAS_DL_LIB=Off                                         \
+      -DLIBUNWIND_HAS_PTHREAD_LIB=Off
+  $ ninja
+
+
+``LIBUNWIND_HAS_COMMENT_LIB_PRAGMA``, ``LIBUNWIND_HAS_DL_LIB``, and
+``LIBUNWIND_HAS_PTHREAD_LIB`` are not strictly necessary, but are useful to
+prevent requiring your libunwind dependents to also link with libdl and
+libpthread.
+
+## Verifying your results
+
+This gets you a copy of libunwind with the libgcc symbols. You can verify this
+using ``readelf``.
+
+.. code-block:: bash
+
+  # Assumes $(PWD) is /path/to/llvm-project/build/libunwind
+  $ readelf -su lib/libunwind.so | grep FUNC | grep GCC_3.0
+
+
+Roughly sixty symbols should appear, all suffixed with ``@@GCC_3.0``. You can
+replace ``GCC_3.0`` with any of the supported version names in the version
+script you’re exporting to verify that the symbols are exported.

libunwind/gcc_s-aarch64.ver

+GCC_3.0 {
+  _Unwind_DeleteException;
+  _Unwind_Find_FDE;
+  _Unwind_ForcedUnwind;
+  _Unwind_GetDataRelBase;
+  _Unwind_GetGR;
+  _Unwind_GetIP;
+  _Unwind_GetLanguageSpecificData;
+  _Unwind_GetRegionStart;
+  _Unwind_GetTextRelBase;
+  _Unwind_RaiseException;
+  _Unwind_Resume;
+  _Unwind_SetGR;
+  _Unwind_SetIP;
+  __absvdi2;
+  __absvsi2;
+  __addtf3;
+  __addvdi3;
+  __addvsi3;
+  __ashlti3;
+  __ashrti3;
+  __clear_cache;
+  __cmpti2;
+  __divtf3;
+  __divti3;
+  __eqtf2;
+  __extenddftf2;
+  __extendsftf2;
+  __ffsdi2;
+  __ffsti2;
+  __fixdfti;
+  __fixsfti;
+  __fixtfdi;
+  __fixtfsi;
+  __fixtfti;
+  __fixunsdfdi;
+  __fixunsdfti;
+  __fixunssfdi;
+  __fixunssfti;
+  __fixunstfdi;
+  __fixunstfsi;
+  __fixunstfti;
+  __floatditf;
+  __floatsitf;
+  __floattidf;
+  __floattisf;
+  __floattitf;
+  __getf2;
+  __gttf2;
+  __letf2;
+  __lshrti3;
+  __lttf2;
+  __modti3;
+  __multf3;
+  __multi3;
+  __mulvdi3;
+  __mulvsi3;
+  __negti2;
+  __negvdi2;
+  __negvsi2;
+  __netf2;
+  __subtf3;
+  __subvdi3;
+  __subvsi3;
+  __trunctfdf2;
+  __trunctfsf2;
+  __ucmpti2;
+  __udivmodti4;
+  __udivti3;
+  __umodti3;
+};
+
+GCC_3.3 {
+  _Unwind_Backtrace;
+  _Unwind_FindEnclosingFunction;
+  _Unwind_GetCFA;
+  _Unwind_Resume_or_Rethrow;
+};
+
+GCC_3.3.1 {
+  __gcc_personality_v0;
+};
+
+GCC_3.4 {
+  __clzdi2;
+  __clzti2;
+  __ctzdi2;
+  __ctzti2;
+  __paritydi2;
+  __parityti2;
+  __popcountdi2;
+  __popcountti2;
+};
+
+GCC_3.4.2 {
+  __enable_execute_stack;
+};
+
+GCC_3.4.4 {
+  __absvti2;
+  __addvti3;
+  __mulvti3;
+  __negvti2;
+  __subvti3;
+};
+
+GCC_4.0.0 {
+  __divdc3;
+  __divsc3;
+  __divtc3;
+  __muldc3;
+  __mulsc3;
+  __multc3;
+  __powidf2;
+  __powisf2;
+  __powitf2;
+};
+
+GCC_4.2.0 {
+  _Unwind_GetIPInfo;
+  __floatunditf;
+  __floatunsitf;
+  __floatuntidf;
+  __floatuntisf;
+  __floatuntitf;
+};
+
+GCC_4.3.0 {
+  __bswapdi2;
+  __bswapsi2;
+  __emutls_get_address;
+};
+
+GCC_4.5.0 {
+  __unordtf2;
+};
+
+GCC_7.0.0 {
+  __divmodti4;
+};
+
+GLIBC_2.0 {
+  __deregister_frame;
+  __register_frame;
+};
+
+Unversioned {
+  __extendhftf2;
+  __trunctfhf2;
+  emutls_init;
+};
+

libunwind/gcc_s-armv7a.ver

+GCC_3.0 {
+  _Unwind_DeleteException;
+  _Unwind_GetDataRelBase;
+  _Unwind_GetLanguageSpecificData;
+  _Unwind_GetRegionStart;
+  _Unwind_GetTextRelBase;
+  _Unwind_RaiseException;
+  _Unwind_Resume;
+  __absvdi2;
+  __absvsi2;
+  __adddf3;
+  __addsf3;
+  __addvdi3;
+  __addvsi3;
+  __ashldi3;
+  __ashrdi3;
+  __clear_cache;
+  __cmpdi2;
+  __divdf3;
+  __divsf3;
+  __divsi3;
+  __eqdf2;
+  __eqsf2;
+  __extendsfdf2;
+  __ffsdi2;
+  __fixdfdi;
+  __fixdfsi;
+  __fixsfdi;
+  __fixsfsi;
+  __fixunsdfdi;
+  __fixunsdfsi;
+  __fixunssfdi;
+  __fixunssfsi;
+  __floatdidf;
+  __floatdisf;
+  __floatsidf;
+  __floatsisf;
+  __gedf2;
+  __gesf2;
+  __gtdf2;
+  __gtsf2;
+  __ledf2;
+  __lesf2;
+  __lshrdi3;
+  __ltdf2;
+  __ltsf2;
+  __modsi3;
+  __muldf3;
+  __muldi3;
+  __mulsf3;
+  __mulvdi3;
+  __mulvsi3;
+  __nedf2;
+  __negdf2;
+  __negdi2;
+  __negsf2;
+  __negvdi2;
+  __negvsi2;
+  __nesf2;
+  __subdf3;
+  __subsf3;
+  __subvdi3;
+  __subvsi3;
+  __truncdfsf2;
+  __ucmpdi2;
+  __udivmoddi4;
+  __udivsi3;
+  __umodsi3;
+};
+
+GCC_3.3 {
+  _Unwind_GetCFA;
+  _Unwind_Resume_or_Rethrow;
+};
+
+GCC_3.3.1 {
+  __gcc_personality_v0;
+};
+
+GCC_3.3.4 {
+  __unorddf2;
+  __unordsf2;
+};
+
+GCC_3.4 {
+  __clzdi2;
+  __clzsi2;
+  __ctzdi2;
+  __ctzsi2;
+  __paritydi2;
+  __paritysi2;
+  __popcountdi2;
+  __popcountsi2;
+};
+
+GCC_3.4.2 {
+  __enable_execute_stack;
+};
+
+GCC_3.5 {
+  _Unwind_Complete;
+  _Unwind_VRS_Get;
+  _Unwind_VRS_Pop;
+  _Unwind_VRS_Set;
+  __aeabi_cdcmpeq;
+  __aeabi_cdcmple;
+  __aeabi_cdrcmple;
+  __aeabi_cfcmpeq;
+  __aeabi_cfcmple;
+  __aeabi_cfrcmple;
+  __aeabi_d2f;
+  __aeabi_d2iz;
+  __aeabi_d2lz;
+  __aeabi_d2uiz;
+  __aeabi_d2ulz;
+  __aeabi_dadd;
+  __aeabi_dcmpeq;
+  __aeabi_dcmpge;
+  __aeabi_dcmpgt;
+  __aeabi_dcmple;
+  __aeabi_dcmplt;
+  __aeabi_dcmpun;
+  __aeabi_ddiv;
+  __aeabi_dmul;
+  __aeabi_dneg;
+  __aeabi_drsub;
+  __aeabi_dsub;
+  __aeabi_f2d;
+  __aeabi_f2iz;
+  __aeabi_f2lz;
+  __aeabi_f2uiz;
+  __aeabi_f2ulz;
+  __aeabi_fadd;
+  __aeabi_fcmpeq;
+  __aeabi_fcmpge;
+  __aeabi_fcmpgt;
+  __aeabi_fcmple;
+  __aeabi_fcmplt;
+  __aeabi_fcmpun;
+  __aeabi_fdiv;
+  __aeabi_fmul;
+  __aeabi_fneg;
+  __aeabi_frsub;
+  __aeabi_fsub;
+  __aeabi_i2d;
+  __aeabi_i2f;
+  __aeabi_idiv;
+  __aeabi_idiv0;
+  __aeabi_idivmod;
+  __aeabi_l2d;
+  __aeabi_l2f;
+  __aeabi_lasr;
+  __aeabi_lcmp;
+  __aeabi_ldiv0;
+  __aeabi_ldivmod;
+  __aeabi_llsl;
+  __aeabi_llsr;
+  __aeabi_lmul;
+  __aeabi_ui2d;
+  __aeabi_ui2f;
+  __aeabi_uidiv;
+  __aeabi_uidivmod;
+  __aeabi_ul2d;
+  __aeabi_ul2f;
+  __aeabi_ulcmp;
+  __aeabi_uldivmod;
+  __aeabi_unwind_cpp_pr0;
+  __aeabi_unwind_cpp_pr1;
+  __aeabi_unwind_cpp_pr2;
+  __gnu_unwind_frame;
+};
+
+GCC_4.0.0 {
+  __divdc3;
+  __divsc3;
+  __muldc3;
+  __mulsc3;
+  __powidf2;
+  __powisf2;
+};
+
+GCC_4.2.0 {
+  __floatundidf;
+  __floatundisf;
+  __floatunsidf;
+  __floatunsisf;
+};
+
+GCC_4.3.0 {
+  _Unwind_Backtrace;
+  __bswapdi2;
+  __bswapsi2;
+  __emutls_get_address;
+  __ffssi2;
+};
+
+GCC_7.0.0 {
+  __divmoddi4;
+};
+
+GLIBC_2.0 {
+  __divdi3;
+  __moddi3;
+  __udivdi3;
+  __umoddi3;
+};
+
+Unversioned {
+  _Unwind_GetGR;
+  _Unwind_SetGR;
+  __cmpdf2;
+  __cmpsf2;
+  emutls_init;
+};
+

libunwind/gcc_s-i386.ver

+GCC_3.0 {
+  _Unwind_DeleteException;
+  _Unwind_Find_FDE;
+  _Unwind_ForcedUnwind;
+  _Unwind_GetDataRelBase;
+  _Unwind_GetGR;
+  _Unwind_GetIP;
+  _Unwind_GetLanguageSpecificData;
+  _Unwind_GetRegionStart;
+  _Unwind_GetTextRelBase;
+  _Unwind_RaiseException;
+  _Unwind_Resume;
+  _Unwind_SetGR;
+  _Unwind_SetIP;
+  __absvdi2;
+  __absvsi2;
+  __addvdi3;
+  __addvsi3;
+  __ashldi3;
+  __ashrdi3;
+  __clear_cache;
+  __cmpdi2;
+  __deregister_frame_info_bases;
+  __ffsdi2;
+  __fixdfdi;
+  __fixsfdi;
+  __fixunsdfdi;
+  __fixunsdfsi;
+  __fixunssfdi;
+  __fixunssfsi;
+  __fixunsxfdi;
+  __fixunsxfsi;
+  __fixxfdi;
+  __floatdidf;
+  __floatdisf;
+  __floatdixf;
+  __lshrdi3;
+  __muldi3;
+  __mulvdi3;
+  __mulvsi3;
+  __negdi2;
+  __negvdi2;
+  __negvsi2;
+  __register_frame_info_bases;
+  __register_frame_info_table_bases;
+  __subvdi3;
+  __subvsi3;
+  __ucmpdi2;
+  __udivmoddi4;
+};
+
+GCC_3.3 {
+  _Unwind_Backtrace;
+  _Unwind_FindEnclosingFunction;
+  _Unwind_GetCFA;
+  _Unwind_Resume_or_Rethrow;
+};
+
+GCC_3.3.1 {
+  __gcc_personality_v0;
+};
+
+GCC_3.4 {
+  __clzdi2;
+  __clzsi2;
+  __ctzdi2;
+  __ctzsi2;
+  __paritydi2;
+  __paritysi2;
+  __popcountdi2;
+  __popcountsi2;
+};
+
+GCC_3.4.2 {
+  __enable_execute_stack;
+};
+
+GCC_4.0.0 {
+  __divdc3;
+  __divsc3;
+  __divxc3;
+  __muldc3;
+  __mulsc3;
+  __mulxc3;
+  __powidf2;
+  __powisf2;
+  __powixf2;
+};
+
+GCC_4.2.0 {
+  _Unwind_GetIPInfo;
+  __floatundidf;
+  __floatundisf;
+  __floatundixf;
+};
+
+GCC_4.3.0 {
+  __bswapdi2;
+  __bswapsi2;
+  __emutls_get_address;
+  __ffssi2;
+};
+
+GCC_4.8.0 {
+  __cpu_indicator_init;
+};
+
+GCC_7.0.0 {
+  __divmoddi4;
+};
+
+GLIBC_2.0 {
+  __deregister_frame;
+  __deregister_frame_info;
+  __divdi3;
+  __moddi3;
+  __register_frame;
+  __register_frame_info;
+  __register_frame_info_table;
+  __register_frame_table;
+  __udivdi3;
+  __umoddi3;
+};
+
+Unversioned {
+  emutls_init;
+};
+

libunwind/gcc_s-x86_64.ver

+GCC_3.0 {
+  _Unwind_DeleteException;
+  _Unwind_Find_FDE;
+  _Unwind_ForcedUnwind;
+  _Unwind_GetDataRelBase;
+  _Unwind_GetGR;
+  _Unwind_GetIP;
+  _Unwind_GetLanguageSpecificData;
+  _Unwind_GetRegionStart;
+  _Unwind_GetTextRelBase;
+  _Unwind_RaiseException;
+  _Unwind_Resume;
+  _Unwind_SetGR;
+  _Unwind_SetIP;
+  __absvdi2;
+  __absvsi2;
+  __addvdi3;
+  __addvsi3;
+  __ashlti3;
+  __ashrti3;
+  __clear_cache;
+  __cmpti2;
+  __deregister_frame;
+  __deregister_frame_info;
+  __deregister_frame_info_bases;
+  __divti3;
+  __ffsdi2;
+  __ffsti2;
+  __fixdfti;
+  __fixsfti;
+  __fixunsdfdi;
+  __fixunsdfti;
+  __fixunssfdi;
+  __fixunssfti;
+  __fixunsxfdi;
+  __fixunsxfti;
+  __fixxfti;
+  __floattidf;
+  __floattisf;
+  __floattixf;
+  __lshrti3;
+  __modti3;
+  __multi3;
+  __mulvdi3;
+  __mulvsi3;
+  __negti2;
+  __negvdi2;
+  __negvsi2;
+  __register_frame;
+  __register_frame_info;
+  __register_frame_info_bases;
+  __register_frame_info_table;
+  __register_frame_info_table_bases;
+  __register_frame_table;
+  __subvdi3;
+  __subvsi3;
+  __ucmpti2;
+  __udivmodti4;
+  __udivti3;
+  __umodti3;
+};
+
+GCC_3.3 {
+  _Unwind_Backtrace;
+  _Unwind_FindEnclosingFunction;
+  _Unwind_GetCFA;
+  _Unwind_Resume_or_Rethrow;
+};
+
+GCC_3.3.1 {
+  __gcc_personality_v0;
+};
+
+GCC_3.4 {
+  __clzdi2;
+  __clzti2;
+  __ctzdi2;
+  __ctzti2;
+  __paritydi2;
+  __parityti2;
+  __popcountdi2;
+  __popcountti2;
+};
+
+GCC_3.4.2 {
+  __enable_execute_stack;
+};
+
+GCC_3.4.4 {
+  __absvti2;
+  __addvti3;
+  __mulvti3;
+  __negvti2;
+  __subvti3;
+};
+
+GCC_4.0.0 {
+  __divdc3;
+  __divsc3;
+  __divxc3;
+  __muldc3;
+  __mulsc3;
+  __mulxc3;
+  __powidf2;
+  __powisf2;
+  __powixf2;
+};
+
+GCC_4.2.0 {
+  _Unwind_GetIPInfo;
+  __floatuntidf;
+  __floatuntisf;
+  __floatuntixf;
+};
+
+GCC_4.3.0 {
+  __bswapdi2;
+  __bswapsi2;
+  __divtc3;
+  __emutls_get_address;
+  __multc3;
+};
+
+GCC_4.8.0 {
+  __cpu_indicator_init;
+};
+
+GCC_7.0.0 {
+  __divmodti4;
+};
+
+Unversioned {
+  emutls_init;
+};
+

libunwind/src/CMakeLists.txt

 
 set(LIBUNWIND_SOURCES
     ${LIBUNWIND_CXX_SOURCES}
     ${LIBUNWIND_C_SOURCES}
     ${LIBUNWIND_ASM_SOURCES})
 
 # Generate library list.
 add_library_flags_if(LIBUNWIND_HAS_C_LIB c)
-if (LIBUNWIND_USE_COMPILER_RT)
+
+if (LIBUNWIND_SYNTH_LIBGCC)
+  message(STATUS "LIBUNWIND_SYNTH_LIBGCC set to ${LIBUNWIND_SYNTH_LIBGCC}")
+  set(LIBGCC_S_VERSION_SCRIPT_PATH "${CMAKE_CURRENT_SOURCE_DIR}/../gcc_s-${LIBUNWIND_SYNTH_LIBGCC}.ver")
+  if (NOT EXISTS "${LIBGCC_S_VERSION_SCRIPT_PATH}")
+    message(SEND_ERROR
+      "Cannot synthesise libgcc_s for ${LIBUNWIND_SYNTH_LIBGCC} because ${LIBGCC_S_VERSION_SCRIPT_PATH} doesn't exist.")
+  endif()
+
+  add_library_flags(
+    "-nostdlib"
+    "-Wl,--whole-archive"
+    "${LIBUNWIND_BUILTINS_LIBRARY}"
+    "-Wl,--version-script,${CMAKE_CURRENT_SOURCE_DIR}/../gcc_s-${LIBUNWIND_SYNTH_LIBGCC}.ver"
+    "-Wl,--no-whole-archive")
+    add_library_flags_if(LIBUNWIND_HAS_PTHREAD_LIB pthread)
+    add_library_flags_if(LIBUNWIND_HAS_M_LIB m)
+elseif (LIBUNWIND_USE_COMPILER_RT)
   add_library_flags("${LIBUNWIND_BUILTINS_LIBRARY}")
 else()
   add_library_flags_if(LIBUNWIND_HAS_GCC_S_LIB gcc_s)
   add_library_flags_if(LIBUNWIND_HAS_GCC_LIB gcc)
 endif()
 add_library_flags_if(LIBUNWIND_HAS_DL_LIB dl)
 if (LIBUNWIND_ENABLE_THREADS)
   add_library_flags_if(LIBUNWIND_HAS_PTHREAD_LIB pthread)
PROPERTIES
       COMPILE_FLAGS "${LIBUNWIND_COMPILE_FLAGS}"
       LINK_FLAGS "${LIBUNWIND_LINK_FLAGS}"
       LINKER_LANGUAGE C
       OUTPUT_NAME "unwind"
       VERSION "1.0"
       SOVERSION "1"
       POSITION_INDEPENDENT_CODE ON
   )
+
+  if (LIBUNWIND_SYNTH_LIBGCC)
+    add_custom_target(synth_libgcc_s ALL
+      DEPENDS unwind_shared
+      COMMAND ${CMAKE_COMMAND} -E create_symlink
+        "libunwind.so" "${CMAKE_LIBRARY_OUTPUT_DIRECTORY}/libgcc_s.so")
+    add_custom_target(synth_libgcc_s1 ALL
+      DEPENDS unwind_shared
+      COMMAND ${CMAKE_COMMAND} -E create_symlink
+        "libunwind.so.1" "${CMAKE_LIBRARY_OUTPUT_DIRECTORY}/libgcc_s.so.1")
+  endif()
+
   list(APPEND LIBUNWIND_BUILD_TARGETS "unwind_shared")
   if (LIBUNWIND_INSTALL_SHARED_LIBRARY)
     list(APPEND LIBUNWIND_INSTALL_TARGETS "unwind_shared")
   endif()
 endif()
 
 # Build the static library.
 if (LIBUNWIND_ENABLE_STATIC)
if (LIBUNWIND_ENABLE_STATIC)
 
   if(LIBUNWIND_HIDE_SYMBOLS)
     append_flags_if_supported(UNWIND_STATIC_LIBRARY_FLAGS -fvisibility=hidden)
     append_flags_if_supported(UNWIND_STATIC_LIBRARY_FLAGS -fvisibility-global-new-delete-hidden)
     target_compile_options(unwind_static PRIVATE ${UNWIND_STATIC_LIBRARY_FLAGS})
     target_compile_definitions(unwind_static PRIVATE _LIBUNWIND_HIDE_SYMBOLS)
   endif()
 
+  if (LIBUNWIND_SYNTH_LIBGCC)
+    add_custom_target(synth_libgcc_eha ALL
+      DEPENDS unwind_static
+      COMMAND ${CMAKE_COMMAND} -E create_symlink
+        "libunwind.a" "${CMAKE_LIBRARY_OUTPUT_DIRECTORY}/libgcc_eh.a")
+  endif()
+
   list(APPEND LIBUNWIND_BUILD_TARGETS "unwind_static")
   if (LIBUNWIND_INSTALL_STATIC_LIBRARY)
     list(APPEND LIBUNWIND_INSTALL_TARGETS "unwind_static")
   endif()
 endif()
 
+# Create libgcc (not libgcc_{eh,s}) as a static library regardless of how libunwind is built.
+if (LIBUNWIND_SYNTH_LIBGCC)
+  add_custom_target(synth_libgcc ALL
+    COMMAND ${CMAKE_COMMAND} -E create_symlink
+    "${LIBUNWIND_BUILTINS_LIBRARY}" "${CMAKE_LIBRARY_OUTPUT_DIRECTORY}/libgcc.a")
+endif()
+
 # Add a meta-target for both libraries.
 add_custom_target(unwind DEPENDS ${LIBUNWIND_BUILD_TARGETS})
 
 if (LIBUNWIND_INSTALL_LIBRARY)
+  if (LIBUNWIND_SYNTH_LIBGCC)
+    install(FILES "${CMAKE_LIBRARY_OUTPUT_DIRECTORY}/libgcc.a"
+            TYPE LIB)
+
+    if (LIBUNWIND_ENABLE_STATIC)
+      install(FILES "${CMAKE_LIBRARY_OUTPUT_DIRECTORY}/libgcc_eh.a"
+              TYPE LIB)
+    endif()
+
+    if (LIBUNWIND_ENABLE_SHARED)
+      install(FILES "${CMAKE_LIBRARY_OUTPUT_DIRECTORY}/libgcc_s.so"
+                    "${CMAKE_LIBRARY_OUTPUT_DIRECTORY}/libgcc_s.so.1"
+              TYPE LIB)
+    endif()
+  endif()
   install(TARGETS ${LIBUNWIND_INSTALL_TARGETS}
     LIBRARY DESTINATION ${LIBUNWIND_INSTALL_LIBRARY_DIR} COMPONENT unwind
     ARCHIVE DESTINATION ${LIBUNWIND_INSTALL_LIBRARY_DIR} COMPONENT unwind
     RUNTIME DESTINATION bin COMPONENT unwind)
 endif()
 
 if (NOT CMAKE_CONFIGURATION_TYPES AND LIBUNWIND_INSTALL_LIBRARY)
   add_custom_target(install-unwind