[llvm-libgcc] initial commit

[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][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 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][3], and this
CL 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.html

[cjdb]

The core missing functionality for this revision is that I'm struggling to work out how to get this to build in-tree.

[MaskRay]

My suggestion for symbol versioning from D106703 still applies.

Also [5]: https://refspecs.linuxbase.org/LSB_4.1.0/LSB-Core-generic/LSB-Core-generic/libgcc-s.html should be replaced with a link to 5.0.0

[MaskRay]

llvm/libgcc/docs/LLVMLibgcc.rst

68

Does LLVM_DEFAULT_TARGET_TRIPLE help?

183

readelf -W --dyn-syms

186

There are many symbols of other versions.

llvm/libgcc/lib/CMakeLists.txt

3

The name "unwind" may be confused with llvm-project/libunwind

[tschuett]

Is this a new top-level project or something hidden in the llvm directory? In the later case, why isn't in llvm/tools or llvm/utils?

[danielkiss]

gcc_s-armhf.ver version script (copy/symlink of armv7) is needed too.

llvm/libgcc/FindCompilerRT.cmake

1

CMake complained about the missing reference:
+include(CheckLibraryExists)

48–49

maybe just say:
check_library_exists("libclang_rt.builtins-${LLVM_LIBGCC_TARGET}.a" emutls_key_destructor "${LLVM_LIBGCC_COMPILER_RT_DIR}")

llvm/libgcc/docs/LLVMLibgcc.rst

168

typo

llvm/libgcc/lib/CMakeLists.txt

16–17

This worked for me, other wise the path was wrong:

-  -Wl,${LLVM_LIBGCC_SYSROOT}/lib${LLVMLIB_DIR_SUFFIX}/${LLVM_LIBGCC_COMPILER_RT}
-  -Wl,${LLVM_LIBGCC_SYSROOT}/lib${LLVMLIB_DIR_SUFFIX}/${LLVM_LIBGCC_UNWIND_STATIC}
+  -Wl,${LLVM_LIBGCC_COMPILER_RT}
+  -Wl,${LLVM_LIBGCC_UNWIND_STATIC}

[cjdb]

• applies most of the feedback in the CL
• adds a Python script that generates new linker version scripts instead of requiring developers to do it by hand

llvm/libgcc/docs/LLVMLibgcc.rst

68

Possibly, but there can be ambiguity between x86 and x86_64 since x86 chips aren't really a thing any more and the two terms are often interchangeable.

186

Yes. It's not really clear to me why you're pointing this out though.

[tschuett]

I prefer: #!/usr/bin/env python3

and

def main():
  return 0

if __name__ == "__main__":
    sys.exit(main())

https://docs.python.org/3/library/__main__.html#idiomatic-usage

[MaskRay]

llvm/tools/llvm-libgcc/generate_version_script.py

9 ↗

(On Diff #399780)

docstring formatting is not aligned

67 ↗

(On Diff #399780)

llvm-readelf and drop --wide

126 ↗

(On Diff #399780)

Single quotes

llvm/tools/llvm-libgcc/version-scripts/gcc_s-i386.ver

124 ↗

(On Diff #399780)

delete trailing blank lines

[cjdb]

updating to C symver file

[cjdb]

restores the version scripts, but instead makes them generated when invoking the build

[cjdb]

updates documentation to reflect status quo

[cjdb]

• collapses the version script preprocessing into a single version script that's now run through the C preprocessor
• adds pseudo-detection for arm-*-*-gnueabihf

[cjdb]

llvm/tools/llvm-libgcc/FindCompilerRT.cmake

47 ↗

(On Diff #403735)

We might need to do some magic here to cover libclang_rt.builtins-x86_64.a, etc.

[MaskRay]

Thanks for the update.

${CMAKE_C_COMPILER}" "-E" "-xc" "${CMAKE_CURRENT_SOURCE_DIR}/gcc_s.ver" "-o" "${CMAKE_CURRENT_BINARY_DIR}/gcc_s.ver"

Yeah. This CC -E preprocessed version script is what I like to happen in a comment last year (https://reviews.llvm.org/D106703#2940320) and the style favored by jyknight.

You may use llvm-nm -jUD /lib/x86_64-linux-gnu/libgcc_s.so.1 to get versioned defined symbols. Could you please comparing the symbol set with GCC libgcc_s.so.1 for these architectures you mostly care about?
Knowing which symbols are missing and have mismatched versions will be useful. I spot checked a small set of symbols and found some minor issues.
If 32-bit arm is so different from other architectures, perhaps use a global ifdef like

#ifdef __arm__
....
#else
...
#endif

instead of special casing #ifdef __arm__ (or the like) in every version node.

ld.lld has diagnostics if

• an exact pattern occurs in two version nodes
• or an exact pattern does not match any symbol

You may want to check there is no such warning.

llvm/tools/llvm-libgcc/lib/gcc_s.ver

49 ↗

(On Diff #403735)

Looks like __addtf3 for x86-64 is in GCC_4.3.0. You may need a comment documenting which architecture is the outlier here.

64 ↗

(On Diff #403735)

__register_frame_info and its friends are generic. See llvm-nm -jDU /usr/aarch64-linux-gnu/lib/libgcc_s.so.1 if you have installed aarch64 GCC cross compiler on a Debian/Ubuntu like distro.

179 ↗

(On Diff #403735)

__addtf3 and its friends are missing here.

% llvm-nm -jDU /lib/x86_64-linux-gnu/libgcc_s.so.1 | grep addtf3     
__addtf3@@GCC_4.3.0

197 ↗

(On Diff #403735)

This symbol is also in /usr/powerpc64le-linux-gnu/lib/libgcc_s.so.1.

If just arm is weird, exclude it.

[danielkiss]

Thanks for update.

llvm/tools/llvm-libgcc/lib/CMakeLists.txt

30–31 ↗

(On Diff #403735)

These two libs could be added as dependency too as gcc_s_ver.

llvm/tools/llvm-libgcc/lib/gcc_s.ver

4 ↗

(On Diff #403735)

that should work as
__ARM_FP means HW floating point is available as
• Bit 1 - half precision (16-bit).
• Bit 2 - single precision (32-bit).
• Bit 3 - double precision (64-bit).
or
• 0x04 for single-support.
• 0x0C for single- and double-support.
• 0x0E for half-, single-, and double-support.

[cjdb]

• re-adds generate_version_script.py
• responds to @MaskRay's feedback

[cjdb]

In D108416#3277189, @MaskRay wrote:

Could you please comparing the symbol set with GCC libgcc_s.so.1 for these architectures you mostly care about?

Done for x86_64 just now, will move on to the others shortly.
I'd actually like to get some sort of pre-commit CI on this subproject if at all possible, but I'm not entirely sure how to do that.

Knowing which symbols are missing and have mismatched versions will be useful. I spot checked a small set of symbols and found some minor issues.
If 32-bit arm is so different from other architectures, perhaps use a global ifdef like

#ifdef __arm__
....
#else
...
#endif

instead of special casing #ifdef __arm__ (or the like) in every version node.

Is it really that unwieldy?

llvm/tools/llvm-libgcc/generate_version_script.py

67 ↗

(On Diff #399780)

Why drop --wide?

llvm/tools/llvm-libgcc/lib/gcc_s.ver

64 ↗

(On Diff #403735)

Yep, but they're apparently versioned under GLIBC_2.0 for everything else :-(

179 ↗

(On Diff #403735)

__addtf3 is in neither libclang_rt.builtins-x86_64.a nor libunwind.a for x86-64, which is why it's omitted here. I think we'd need to add it to libclang_rt.builtins-x86_64 in order for it to be usable?

197 ↗

(On Diff #403735)

Looks like this is a 64-bit global symbol. I've updated the documentation to indicate which platforms are supported at the moment, and how to expand support for platforms like PowerPC.

[cjdb]

applies @danielkiss' feedback

llvm/tools/llvm-libgcc/lib/gcc_s.ver

4 ↗

(On Diff #403735)

Should it be __ARM_FP == 0xC or __ARM_FP >= 0x04?

[cjdb]

changes how the version script is laid out so that global symbols are all listed first, and exclusive symbols are listed afterward

[MaskRay]

llvm/tools/llvm-libgcc/lib/gcc_s.ver

16 ↗

(On Diff #404168)

You may use __LP64__

20 ↗

(On Diff #404168)

__LP64__

Unsure anyone will use this for ILP64. Sticking with LP64 and !__LP64__ should be fine.

[cjdb]

changes how GLOBAL_32BIT and GLOBAL_64BIT are enabled

llvm/tools/llvm-libgcc/lib/gcc_s.ver

20 ↗

(On Diff #404168)

Eh, it's not that much extra work to support it, especially if we use #else on the tail of 64-bit detection.

[arichardson]

llvm/tools/llvm-libgcc/lib/gcc_s.ver

20 ↗

(On Diff #404168)

If you use __SIZEOF_POINTER__ >= 8 it should also do the right thing when compiling for Arm Morello (which is L64P128)

[cjdb]

changes to SIZEOF_POINTER >= 8

[danielkiss]

llvm/tools/llvm-libgcc/lib/gcc_s.ver

4 ↗

(On Diff #403735)

__ARM_FP >= 0x04 is better because on some targets the 64bit operations are available.

[cjdb]

broadens armhf detection

[MaskRay]

Thanks for the update. From a high level,

• llvm-libgcc looks useful to me
• the refactored gcc_s.ver looks good to me.
• I'd wish that some CMake experts (e.g. @phosek @compnerd) can review the CMake logic, which is a significant portion of this patch. I am hesitant to LGTM this part.
• the motivation in the summary and the documentation focus on glibc loading libgcc_s.so.1, and people may wonder whether other systems (e.g. Linux musl) need this? If glibc is patched to not dlopen libgcc_so.so.1, is it still a problem? I think the symbol version will remain as a problem for GCC prebuilt objects. The documentation just doesn't make this as a clear motivation.
• apparently many folks are interested (therefore the comments). Ideally hope someone can stand up to test that the symbol versioning result is indeed closer to libgcc_s.so.1 ... (Sorry, it may not be me.)

[tschuett]

llvm/tools/llvm-libgcc/generate_version_script.py

1 ↗

(On Diff #405035)

#!/usr/bin/env python3 looks safer.

[compnerd]

llvm/tools/llvm-libgcc/CMakeLists.txt

7 ↗

(On Diff #405035)

Perhaps we can default the path since the layout is now fairly uniform due to the merged repository layout.

36 ↗

(On Diff #405035)

I think that bin rather than lib is appropriate. The CMAKE_RUNTIME_OUTPUT_DIRECTORY is used for the executables and dlls on Windows.

llvm/tools/llvm-libgcc/FindCompilerRT.cmake

1 ↗

(On Diff #405035)

I think that this is not really the way to do this. This should follow the standard CMake expectations around the behaviour of Find*.cmake. Alternatively, you could name this something else and completely elide the find_* usage.

91 ↗

(On Diff #405035)

This should be hoisted into the top level CMake. The FindCompilerRT.cmake should only search for the prebuilt version.

llvm/tools/llvm-libgcc/FindLLVMLibunwind.cmake

1 ↗

(On Diff #405035)

Similar

llvm/tools/llvm-libgcc/lib/CMakeLists.txt

17 ↗

(On Diff #405035)

add_custom_command by itself is difficult to use, please create a target to track the output so that dependencies can be wired properly.

30 ↗

(On Diff #405035)

Is there a reason to not use -nostdlib as a driver level option?

33 ↗

(On Diff #405035)

Is there a guarantee that we are not building these libraries? If we are building these libraries, I think that it would be better to use the target objects (i.e. $<TARGET_OBJECTS:unwind> rather than the --whole-archive, --no-whole-archive path.

34 ↗

(On Diff #405035)

I think that this should be outside of the -(, -).

38 ↗

(On Diff #405035)

This seems like an odd check. I think that we should drop it, libc is required and unless you are suggesting that it is possible to have a freestanding build of this library, we should assume that it is available. (I think that it is still problematic for non-Unix platforms due to spelling but we can deal with that if/when necessary as libgcc is not something that really applies there).

55 ↗

(On Diff #405035)

I would rather use ${CMAKE_SHARED_LIBRARY_PREFIX} and ${CMAKE_SHARED_LIBRARY_SUFFIX}. rather than lib and .so.

59 ↗

(On Diff #405035)

I think that the versioned symlinks should point to the same names not to the peers.

[cjdb]

gets CMake scripts into a decent state

[cjdb]

quick CMake fix

[compnerd]

llvm-libgcc/CMakeLists.txt

10 ↗

(On Diff #408690)

Any reason for insert rather that append?

36 ↗

(On Diff #408690)

I tend to prefer all caps for the On and Off, but its equivalent really.

llvm-libgcc/lib/CMakeLists.txt

3 ↗

(On Diff #408690)

newline before this line would be nice.

8 ↗

(On Diff #408690)

I tend to prefer the custom command before the custom target so you can see what the target is generating.

17 ↗

(On Diff #408690)

What differentiates this from the gcc_s_ver target? I think that you have two targets for the same output.

19 ↗

(On Diff #408690)

I think that breaking after the ( is a bit unnecessary:

set_target_properties(gcc_s_version_script PROPERTIES
  OUTPUT_PATH "${CMAKE_CURRENT_BINARY_DIR}/gcc_s.ver")

Similar throughout.

54 ↗

(On Diff #408690)

Dead code?

56 ↗

(On Diff #408690)

Why is this cached?

[compnerd]

I'd like to see at least https://reviews.llvm.org/D108416#inline-1146215, https://reviews.llvm.org/D108416#inline-1146214, and https://reviews.llvm.org/D108416#inline-1146209 addressed pre-commit. Would be nice to have the other ones resolved as well, but they are more stylistic.

[zero9178]

llvm-libgcc/docs/LLVMLibgcc.rst

96 ↗

(On Diff #408690)

neither compiler-rt, nor llvm-libgcc, are listed in LLVM_ENABLE_RUNTIMES

Is this a typo and is meant to be libunwind instead of llvm-libgcc?

[EricWF]

LGTM on behalf of libc++. But please address the comments left by the other reviewers.

[MaskRay]

llvm-libgcc/docs/LLVMLibgcc.rst

97 ↗

(On Diff #408690)

I think some folks prefer that compiler-rt is added to LLVM_ENABLE_RUNTIMES. How difficult is it to make this work?

Note that current plan is that libunwind in DLLVM_ENABLE_PROJECTS will be unsupported.

llvm-libgcc/generate_version_script.py

1 ↗

(On Diff #408690)

/usr/bin/env python3

Add a file-level comment what this script does.

[ldionne]

runtimes/CMakeLists.txt

181–200 ↗

(On Diff #408690)

I think this can be simplified like this:

if("llvm-libgcc" IN_LIST runtimes)
  if("compiler-rt" IN_LIST runtimes OR "compiler-rt" IN_LIST LLVM_ENABLE_PROJECTS)
    message(FATAL_ERROR
      "Attempting to build both compiler-rt and llvm-libgcc will cause irreconcilable "
      "target clashes. Please choose one or the other, but not both.")
  endif()

  if("libunwind" IN_LIST runtimes)
    message(
      FATAL_ERROR
      "Attempting to build both libunwind and llvm-libgcc will cause irreconcilable "
      "target clashes. Please choose one or the other, but not both.")
  endif()
endif()

[cjdb]

responds to feedback

llvm-libgcc/CMakeLists.txt

10 ↗

(On Diff #408690)

I copied this directly from either libunwind/CMakeLists.txt or runtimes/CMakeLists.txt. Looks as if it's being prepended though?

36 ↗

(On Diff #408690)

Acknowledged.

llvm-libgcc/docs/LLVMLibgcc.rst

96 ↗

(On Diff #408690)

Thanks!

97 ↗

(On Diff #408690)

compiler-rt must be listed in neither LLVM_ENABLE_RUNTIMES, nor LLVM_ENABLE_PROJECTS when llvm-libgcc is present. llvm-libgcc will take care of that for you. You can still have LLVM_ENABLE_RUNTIMES=compiler-rt, but not when llvm-libgcc is also in the list.

llvm-libgcc/generate_version_script.py

1 ↗

(On Diff #408690)

Done, but what's the benefit of this?

llvm-libgcc/lib/CMakeLists.txt

19 ↗

(On Diff #408690)

I find the current way to improve readability a lot.

56 ↗

(On Diff #408690)

I think this was user-settable at one point, but per yesterday, this entire variable is redundant.

runtimes/CMakeLists.txt

181–200 ↗

(On Diff #408690)

Thanks, this is way simpler!

[compnerd]

I believe that the break after ( in CMake is counter the style of the rest of the project. I'd recommend against it.

[cjdb]

cleans up a few things

[cjdb]

• makes it harder to accidentally build llvm-libgcc by removing it from LLVM_ENABLE_RUNTIMES=all
• installs shared objects properly

[cjdb]

rebases to activate CI

[phosek]

LGTM

llvm/libgcc/CMakeLists.txt

+cmake_minimum_required(VERSION 3.13.4)
+
+# If we are not building as a part of LLVM, build llvm-libgcc as a standalone
+# project, using compiler-rt and libunwind external libraries.
+if(CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR)
+  project(LLVM_LIBGCC)
+  if(NOT LLVM_LIBGCC_LIBUNWIND_DIR)
+    message(FATAL_ERROR
+      "We're building llvm-libgcc as a standalone project, but we didn't "
+      " supply a path to LLVM_LIBGCC_LIBUNWIND_DIR. It's not possible to build "
+      "llvm-libgcc without this path!")
+  endif()
+endif()
+
+list(APPEND CMAKE_MODULE_PATH "${CMAKE_CURRENT_SOURCE_DIR}")
+
+set(LLVM_LIBGCC_COMPILER_RT_DIR "" CACHE PATH
+    "Absolute path to a pre-existing compiler-rt builtins.")
+find_package(CompilerRT REQUIRED)
+string(REGEX REPLACE "^${LLVM_LIBGCC_SYSROOT}/lib${LLVMLIB_DIR_SUFFIX}/*" ""
+       LLVM_LIBGCC_COMPILER_RT "${LLVM_LIBGCC_COMPILER_RT}")
+
+set(LLVM_LIBGCC_LIBUNWIND_DIR "" CACHE PATH
+    "Absolute path to a pre-existing libunwind.a.")
+find_package(LLVMLibunwind REQUIRED)
+string(REGEX REPLACE "^${LLVM_LIBGCC_SYSROOT}/lib${LLVMLIB_DIR_SUFFIX}/*" ""
+       LLVM_LIBGCC_UNWIND_STATIC "${LLVM_LIBGCC_UNWIND_STATIC}")
+
+message(STATUS "LLVM_LIBGCC_TARGET set to ${LLVM_LIBGCC_TARGET}")
+set(LLVM_LIBGCC_VERSION_SCRIPT_PATH
+    "${CMAKE_CURRENT_SOURCE_DIR}/version-scripts/gcc_s-${LLVM_LIBGCC_TARGET}.ver")
+set(LLVM_LIBGCC_SYSROOT "${CMAKE_INSTALL_PREFIX}" CACHE PATH
+    "Assumes this path as the root directory when setting symlinks.")
+
+if(NOT EXISTS "${LLVM_LIBGCC_VERSION_SCRIPT_PATH}")
+  message(SEND_ERROR
+    "We can't synthesise libgcc_s for '${LLVM_LIBGCC_TARGET}' because "
+    "'${LLVM_LIBGCC_VERSION_SCRIPT_PATH}' doesn't exist. If this target is the "
+    "target that you're after, then we probably need to first generate the "
+    "version script, then re-run CMake.")
+endif()
+
+set(CMAKE_ARCHIVE_OUTPUT_DIRECTORY "${PROJECT_BINARY_DIR}/lib${LLVMLIB_DIR_SUFFIX}")
+set(CMAKE_LIBRARY_OUTPUT_DIRECTORY "${PROJECT_BINARY_DIR}/lib${LLVMLIB_DIR_SUFFIX}")
+set(CMAKE_RUNTIME_OUTPUT_DIRECTORY "${PROJECT_BINARY_DIR}/lib${LLVMLIB_DIR_SUFFIX}")
+
+add_subdirectory(lib)

llvm/libgcc/FindCompilerRT.cmake

+include(FindPackageHandleStandardArgs)
+
+function(building_compiler_rt)
+  if(LLVM_LIBGCC_COMPILER_RT_DIR)
+    return()
+  endif()
+
+  list(FIND LLVM_ENABLE_PROJECTS compiler-rt LLVM_LIBGCC_HAS_COMPILER_RT)
+  if(NOT LLVM_LIBGCC_HAS_COMPILER_RT)
+    return()
+  endif()
+
+  if(NOT COMPILER_RT_BUILD_BUILTINS)
+    message(SEND_ERROR
+      "When building llvm-libgcc alongside compiler-rt, we need to set "
+      "-DCOMPILER_RT_BUILD_BUILTINS=On so we can export all the necessary "
+      "symbols.")
+    return()
+  endif()
+
+  if(NOT COMPILER_RT_BUILTINS_HIDE_SYMBOLS)
+    message(SEND_ERROR
+      "When building llvm-libgcc alongside compiler-rt, we need to set "
+      "-DCOMPILER_RT_BUILTINS_HIDE_SYMBOLS=Off so we can export all the "
+      "necessary symbols.")
+    return()
+  endif()
+
+  set(LLVM_LIBGCC_COMPILER_RT builtins)
+  set(CompilerRT_FOUND ON)
+  message(STATUS "llvm-libgcc is using in-tree compiler-rt")
+endfunction()
+
+function(find_external_compiler_rt)
+  if(NOT ${CMAKE_CHECK_CXX_COMPILER_ID} MATCHES Clang AND
+     NOT LLVM_LIBGCC_COMPILER_RT_DIR)
+    message(STATUS
+      "When building llvm-libgcc without compiler-rt (e.g. as a standalone "
+      "project), we either need to be using Clang, or "
+      "'LLVM_LIBGCC_COMPILER_RT_INSTALL_DIRECTORY' must be set to a directory.")
+    return()
+  endif()
+
+  if(LLVM_LIBGCC_COMPILER_RT_DIR)
+    set(LLVM_LIBGCC_PATH_TO_RTLIB
+      "${LLVM_LIBGCC_COMPILER_RT_DIR}/libclang_rt.builtins-${LLVM_LIBGCC_TARGET}.a")
+
+    check_library_exists("${LLVM_LIBGCC_PATH_TO_RTLIB}" emutls_key_destructor
+      LLVM_LIBGCC_HAS_EXTERNAL_RTLIB)
+    if (NOT LLVM_LIBGCC_HAS_EXTERNAL_RTLIB)
+      message(SEND_ERROR
+        "When using LLVM_LIBGCC_COMPILER_RT_DIR='${LLVM_LIBGCC_COMPILER_RT_DIR}', "
+        "we couldn't path '${LLVM_LIBGCC_PATH_TO_RTLIB}'. There could be a few "
+        "reasons for this (e.g. typo in path or wrong permissions for file), "
+        "and a manual inspection is necessary.")
+      return()
+    endif()
+
+    set(LLVM_LIBGCC_COMPILER_RT "${LLVM_LIBGCC_PATH_TO_RTLIB}" PARENT_SCOPE)
+    return()
+  endif()
+
+  execute_process(COMMAND "${CMAKE_CXX_COMPILER}"
+    ${CMAKE_CXX_FLAGS}
+    --rtlib=compiler-rt
+    --print-libgcc-file-name
+    RESULT_VARIABLE HAD_ERROR
+    OUTPUT_VARIABLE LLVM_LIBGCC_COMPILER_RT)
+  string(STRIP "${LLVM_LIBGCC_COMPILER_RT}" LLVM_LIBGCC_COMPILER_RT)
+
+  if(HAD_ERROR)
+    message(STATUS "llvm-libgcc unable to find compiler-rt builtins: got return code ${HAD_ERROR}")
+    unset(LLVM_LIBGCC_COMPILER_RT)
+    return()
+  endif()
+
+  if(NOT EXISTS "${LLVM_LIBGCC_COMPILER_RT}")
+    message(STATUS "llvm-libgcc unable to find path '${LLVM_LIBGCC_COMPILER_RT}'")
+    unset(LLVM_LIBGCC_COMPILER_RT)
+  endif()
+
+  set(LLVM_LIBGCC_COMPILER_RT "${LLVM_LIBGCC_COMPILER_RT}" PARENT_SCOPE)
+endfunction()
+
+set(CompilerRT_FOUND OFF)
+if(NOT CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR)
+  building_compiler_rt()
+endif()
+
+if(NOT CompilerRT_FOUND)
+  find_external_compiler_rt()
+  if(LLVM_LIBGCC_COMPILER_RT)
+    message(STATUS "llvm-libgcc is using a pre-installed compiler-rt.")
+    set(CompilerRT_FOUND ON)
+  endif()
+endif()
+
+find_package_handle_standard_args(CompilerRT REQUIRED_VARS CompilerRT_FOUND)

llvm/libgcc/FindLLVMLibunwind.cmake

+include(FindPackageHandleStandardArgs)
+
+function(building_libunwind)
+  list(FIND LLVM_ENABLE_PROJECTS libunwind LLVM_LIBGCC_HAS_LIBUNWIND)
+  if(NOT LLVM_LIBGCC_HAS_LIBUNWIND)
+    return()
+  endif()
+
+  if(NOT LIBUNWIND_USE_COMPILER_RT)
+    message(SEND_ERROR
+      "When we're building llvm-libgcc alongside libunwind, we need to set "
+      "'-DLIBUNWIND_USE_COMPILER_RT=On'.")
+  endif()
+
+  if(LIBUNWIND_INSTALL_SHARED_LIBRARY)
+    message(SEND_ERROR
+      "When we're building llvm-libgcc alongside libunwind, llvm-libgcc will "
+      "be the owner of libunwind.so. To prevent the projects from clashing, we "
+      "need to set '-DLIBUNWIND_INSTALL_SHARED_LIBRARY=Off'.")
+  endif()
+
+  if(NOT (LIBUNWIND_SUPPORTS_FNO_EXCEPTIONS_FLAG AND
+          LIBUNWIND_SUPPORTS_FUNWIND_TABLES_FLAG))
+    message(SEND_ERROR
+      "Compiler doesn't support generation of unwind tables if exception "
+      "support is disabled.  Building libunwind DSO with runtime dependency "
+      "on C++ ABI library is not supported.")
+  endif()
+
+  set(LLVM_LIBGCC_UNWIND_STATIC unwind_static PARENT_SCOPE)
+  set(LLVMLibunwind_FOUND ON PARENT_SCOPE)
+  message(STATUS "llvm-libgcc is using in-tree libunwind")
+endfunction()
+
+function(find_external_libunwind)
+  if (NOT EXISTS "${LLVM_LIBGCC_LIBUNWIND_DIR}/libunwind.a")
+    message(SEND_ERROR
+      "When using LLVM_LIBGCC_LIBUNWIND_DIR='${LLVM_LIBGCC_LIBUNWIND_DIR}', we "
+      "couldn't find '${LLVM_LIBGCC_LIBUNWIND_DIR}/libunwind.a'. There could "
+      "be a few reasons for this (e.g. typo in path or wrong permissions for "
+      "file), and a manual inspection is necessary.")
+  endif()
+
+  set(LLVM_LIBGCC_UNWIND_STATIC "${LLVM_LIBGCC_LIBUNWIND_DIR}/libunwind.a" PARENT_SCOPE)
+  set(LLVMLibunwind_FOUND ON PARENT_SCOPE)
+endfunction()
+
+set(LLVMLibunwind_FOUND OFF)
+if(NOT CMAKE_SOURCE_DIR STREQUAL CMAKE_CURRENT_SOURCE_DIR)
+  building_libunwind()
+else()
+  message(STATUS "llvm-libgcc is using a pre-built libunwind")
+  find_external_libunwind()
+endif()
+
+find_package_handle_standard_args(LLVMLibunwind REQUIRED_VARS LLVMLibunwind_FOUND)

llvm/libgcc/docs/LLVMLibgcc.rst

+.. llvm-libgcc:
+
+===========
+llvm-libgcc
+===========
+
+.. contents::
+  :local:
+
+**Note that these instructions assume a Linux and bash-friendly environment.
+YMMV if you’re on a non Linux-based platform.**
+
+.. _introduction:
+
+Motivation
+============
+
+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 libgcc "front" 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
+distro manager 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.
+
+.. _alternatives
+
+Alternatives
+============
+
+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 cross-talk between
+the differing implementations.
+
+.. _target audience:
+
+Target audience
+===============
+
+llvm-libgcc is not for the casual LLVM user. It is intended to be used by distro
+managers who want to replace libgcc with compiler-rt and libunwind, but cannot
+fully abandon the libgcc family (e.g. because they are dependent on glibc). Such
+managers must have worked out their compatibility requirements ahead of using
+llvm-libgcc.
+
+.. _cmake options:
+
+CMake options
+=============
+
+.. option:: `LLVM_LIBGCC_TARGET`
+
+  **Required**
+
+  The target for which llvm-libgcc is being built. This can't be inferred from
+  ``LLVM_TARGETS_TO_BUILD``, and presently only supports one target at a time.
+
+.. option:: `LLVM_LIBGCC_SYSROOT`
+
+  **Default value**: ``${CMAKE_INSTALL_PREFIX}``
+
+  Transforms an absolute path into a relative path starting from the specified
+  directory. This variable is only used when performing an out-of-tree build.
+
+.. option:: `LLVM_LIBGCC_COMPILER_RT_INSTALL_DIRECTORY`
+
+  Path to compiler-rt. Overrides building compiler-rt in-tree, and is required
+  when building out-of-tree when ``CMAKE_CXX_COMPILER`` isn't Clang.
+
+The following CMake options are not used by llvm-libgcc but are required when
+building in-tree.
+
+.. option:: `COMPILER_RT_BUILD_BUILTINS=On`
+
+.. option:: `COMPILER_RT_BUILTINS_HIDE_SYMBOLS=Off`
+
+  Necessary for exposing symbols that libgcc_s exposes, but compiler-rt doesn't
+  by default. This variable should be set when building libunwind out-of-tree
+  too.
+
+.. option:: `LIBUNWIND_USE_COMPILER_RT=On`
+
+.. option:: `LIBUNWIND_INSTALL_SHARED_LIBRARY`
+
+  llvm-libgcc generates both `libunwind.so` and `libgcc_s.so`, so we want to
+  avoid having libunwind generate this too (otherwise there would be a clash).
+  This variable should be set when building libunwind out-of-tree too.
+
+.. _building llvm-libgcc out of tree
+
+Building llvm-libgcc out of tree
+================================
+
+Building llvm-libgcc out of tree 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                               \
+      -DCMAKE_BUILD_TYPE=Release                           \
+      -DCMAKE_INSTALL_PREFIX=/tmp/llvm-libgcc-experiment   \
+      -DLLVM_ENABLE_PROJECTS='clang;compiler-rt;libunwind' \
+      -DCOMPILER_RT_BUILTINS_HIDE_SYMBOLS=Off              \
+      -DLIBUNWIND_INSTALL_SHARED_LIBRARY=Off               \
+      -DLIBUNWIND_USE_COMPILER_RT=On                       \
+      -DLIBUNWIND_HAS_COMMENT_LIB_PRAGMA=Off               \
+      -DLIBUNWIND_HAS_DL_LIB=Off                           \
+      -DLIBUNWIND_HAS_PTHREAD_LIB=Off
+  $ ninja install
+
+``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.
+
+.. _Building llvm-libgcc
+
+Building llvm-libgcc
+------------------
+
+Now that we've built the prerequisites, we can build llvm-libgcc in a second
+tree. We build llvm-libgcc for x86_64 in this example, but it's possible to
+replicate for any architecture that has a `version script`_ in the
+``version-scripts`` directory (presently i686, x86_64, armhf, 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/llvm-libgcc
+  $ cd build/llvm-libgcc
+  $ LLVM_LIBGCC_SYSROOT=/tmp/llvm-libgcc-experiment
+  $ cmake -GNinja ../../llvm-libgcc                             \
+      -DCMAKE_BUILD_TYPE=Release                                \
+      -DCMAKE_INSTALL_PREFIX="${LLVM_LIBGCC_SYSROOT}"           \
+      -DCMAKE_C_COMPILER="${LLVM_LIBGCC_SYSROOT}/bin/clang"     \
+      -DCMAKE_CXX_COMPILER="${LLVM_LIBGCC_SYSROOT}/bin/clang++" \
+      -DLLVM_LIBGCC_TARGET=x86_64
+  $ ninja install
+
+## Verifying your results
+
+This gets you a copy of libunwind with the libgcc symbols. You can verify this
+using ``readelf``.
+
+.. code-block:: bash
+
+  $ readelf -su "${LLVM_LIBGCC_SYSROOT}/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.

llvm/libgcc/lib/CMakeLists.txt

+include(CheckLibraryExists)
+
+add_library(unwind_shared SHARED blank.cpp)
+set_target_properties(unwind_shared
+  PROPERTIES
+    LINKER_LANGUAGE C
+    OUTPUT_NAME "unwind"
+    VERSION "1.0"
+    SOVERSION "1"
+    POSITION_INDEPENDENT_CODE ON)
+target_link_options(
+  unwind_shared PRIVATE
+  -Wl,-nostdlib
+  -Wl,--whole-archive
+  -Wl,--version-script,${LLVM_LIBGCC_VERSION_SCRIPT_PATH}
+  -Wl,${LLVM_LIBGCC_SYSROOT}/lib${LLVMLIB_DIR_SUFFIX}/${LLVM_LIBGCC_COMPILER_RT}
+  -Wl,${LLVM_LIBGCC_SYSROOT}/lib${LLVMLIB_DIR_SUFFIX}/${LLVM_LIBGCC_UNWIND_STATIC}
+  -Wl,--no-whole-archive
+)
+check_library_exists(m sin "" LLVM_LIBGCC_HAS_LIBM)
+check_library_exists(c printf "" LLVM_LIBGCC_HAS_LIBC)
+target_link_libraries(
+  unwind_shared PRIVATE
+  $<$<BOOL:LLVM_LIBGCC_HAS_LIBM>:m>
+  $<$<BOOL:LLVM_LIBGCC_HAS_LIBC>:c>
+)
+
+add_custom_target(synth_libgcc ALL
+  DEPENDS "${LLVM_LIBGCC_SYSROOT}/lib${LLVMLIB_DIR_SUFFIX}/${LLVM_LIBGCC_COMPILER_RT}" unwind_shared
+  COMMAND ${CMAKE_COMMAND} -E create_symlink
+  "${LLVM_LIBGCC_COMPILER_RT}" "${CMAKE_LIBRARY_OUTPUT_DIRECTORY}/libgcc.a")
+add_custom_target(synth_libgcc_eh ALL
+  COMMAND ${CMAKE_COMMAND} -E create_symlink
+    "${LLVM_LIBGCC_UNWIND_STATIC}" "${CMAKE_LIBRARY_OUTPUT_DIRECTORY}/libgcc_eh.a")
+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")
+
+add_custom_target(unwind
+  DEPENDS
+    unwind_shared
+    synth_libgcc
+    synth_libgcc_eh
+    synth_libgcc_s
+    synth_libgcc_s1)
+set(LLVM_LIBGCC_INSTALL_LIBRARY_DIR lib${LLVM_LIBDIR_SUFFIX} CACHE PATH "")
+install(TARGETS unwind_shared
+        LIBRARY DESTINATION "${LLVM_LIBGCC_INSTALL_LIBRARY_DIR}" COMPONENT unwind
+        ARCHIVE DESTINATION "${LLVM_LIBGCC_INSTALL_LIBRARY_DIR}" COMPONENT unwind
+        RUNTIME DESTINATION bin COMPONENT unwind)
+install(FILES "${CMAKE_LIBRARY_OUTPUT_DIRECTORY}/libgcc.a"      TYPE LIB)
+install(FILES "${CMAKE_LIBRARY_OUTPUT_DIRECTORY}/libgcc_eh.a"   TYPE LIB)
+install(FILES "${CMAKE_LIBRARY_OUTPUT_DIRECTORY}/libgcc_s.so"   TYPE LIB)
+install(FILES "${CMAKE_LIBRARY_OUTPUT_DIRECTORY}/libgcc_s.so.1" TYPE LIB)

llvm/libgcc/version-scripts/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;
+};
+

llvm/libgcc/version-scripts/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;
+};
+

llvm/libgcc/version-scripts/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;
+};
+

llvm/libgcc/version-scripts/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;
+};
+