[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 ↗

(On Diff #367632)

Does LLVM_DEFAULT_TARGET_TRIPLE help?

183 ↗

(On Diff #367632)

readelf -W --dyn-syms

186 ↗

(On Diff #367632)

There are many symbols of other versions.

llvm/libgcc/lib/CMakeLists.txt

3 ↗

(On Diff #367632)

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 ↗

(On Diff #367632)

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

48–49 ↗

(On Diff #367632)

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 ↗

(On Diff #367632)

typo

llvm/libgcc/lib/CMakeLists.txt

16–17 ↗

(On Diff #367632)

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 ↗

(On Diff #367632)

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 ↗

(On Diff #367632)

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

11

Any reason for insert rather that append?

37

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

llvm-libgcc/lib/CMakeLists.txt

4

newline before this line would be nice.

9

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

18

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

20

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.

55

Dead code?

57

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

97

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

98

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

2

/usr/bin/env python3

Add a file-level comment what this script does.

[ldionne]

runtimes/CMakeLists.txt

181–200

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

11

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

37

Acknowledged.

llvm-libgcc/docs/LLVMLibgcc.rst

97

Thanks!

98

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

2

Done, but what's the benefit of this?

llvm-libgcc/lib/CMakeLists.txt

20

I find the current way to improve readability a lot.

57

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

runtimes/CMakeLists.txt

181–200

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

compiler-rt/cmake/Modules/AddCompilerRT.cmake

if(${type} STREQUAL "SHARED")
       endif()
       if(WIN32 AND NOT CYGWIN AND NOT MINGW)
         set_target_properties(${libname} PROPERTIES IMPORT_PREFIX "")
         set_target_properties(${libname} PROPERTIES IMPORT_SUFFIX ".lib")
       endif()
       if(APPLE)
         # Ad-hoc sign the dylibs
         add_custom_command(TARGET ${libname}
-          POST_BUILD  
+          POST_BUILD
           COMMAND codesign --sign - $<TARGET_FILE:${libname}>
           WORKING_DIRECTORY ${COMPILER_RT_OUTPUT_LIBRARY_DIR}
         )
       endif()
     endif()
 
     set(parent_target_arg)
     if(LIB_PARENT_TARGET)

llvm-libgcc/CMakeLists.txt

+cmake_minimum_required(VERSION 3.13.4)
+
+if (NOT IS_DIRECTORY "${CMAKE_CURRENT_LIST_DIR}/../libunwind")
+  message(FATAL_ERROR "llvm-libgcc requires being built in a monorepo layout with libunwind available")
+endif()
+
+set(LLVM_COMMON_CMAKE_UTILS "${CMAKE_CURRENT_SOURCE_DIR}/../cmake")
+
+list(APPEND CMAKE_MODULE_PATH
+  "${CMAKE_CURRENT_SOURCE_DIR}/cmake"
+  "${CMAKE_CURRENT_SOURCE_DIR}/cmake/Modules"
+  "${LLVM_COMMON_CMAKE_UTILS}"
+  "${LLVM_COMMON_CMAKE_UTILS}/Modules"
+  )
+
+project(llvm-libgcc LANGUAGES C CXX ASM)
+
+if(NOT LLVM_LIBGCC_EXPLICIT_OPT_IN)
+  message(FATAL_ERROR
+    "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. If you want to build llvm-libgcc, please add -DLLVM_LIBGCC_EXPLICIT_OPT_IN=Yes "
+    "to your CMake invocation and try again.")
+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}/bin")
+
+set(COMPILER_RT_BUILD_BUILTINS On)
+set(COMPILER_RT_BUILTINS_HIDE_SYMBOLS Off)
+add_subdirectory("../compiler-rt" "compiler-rt")
+
+set(LIBUNWIND_ENABLE_STATIC On)
+set(LIBUNWIND_ENABLE_SHARED Off)
+set(LIBUNWIND_HAS_COMMENT_LIB_PRAGMA Off)
+set(LIBUNWIND_USE_COMPILER_RT On)
+add_subdirectory("../libunwind" "libunwind")
+
+add_subdirectory(lib)

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_EXPLICIT_OPT_IN`
+
+  **Required**
+
+  Since llvm-libgcc is such a fundamental, low-level component, we have made it
+  difficult to accidentally build, by requiring you to set an opt-in flag.
+
+.. _Building llvm-libgcc
+
+Building llvm-libgcc
+--------------------
+
+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
+  $ cmake -GNinja -S llvm -B build-primary                    \
+      -DCMAKE_BUILD_TYPE=Release                              \
+      -DCMAKE_CROSSCOMPILING=On                               \
+      -DCMAKE_INSTALL_PREFIX=/tmp/aarch64-unknown-linux-gnu   \
+      -DLLVM_ENABLE_PROJECTS='clang'                          \
+      -DLLVM_ENABLE_RUNTIMES="libcxx;libcxxabi;llvm-libgcc"   \
+      -DLLVM_TARGETS_TO_BUILD=AArch64                         \
+      -DLLVM_DEFAULT_TARGET_TRIPLE=aarch64-unknown-linux-gnu  \
+      -DLLVM_LIBGCC_EXPLICIT_OPT_IN=Yes
+  $ ninja -C build-primary install
+
+It's very important to notice that neither ``compiler-rt``, nor ``libunwind``,
+are listed in ``LLVM_ENABLE_RUNTIMES``. llvm-libgcc makes these subprojects, and
+adding them to this list will cause you problems due to there being duplicate
+targets. As such, configuring the runtimes build will reject explicitly mentioning
+either project with ``llvm-libgcc``.
+
+To avoid issues when building with ``-DLLVM_ENABLE_RUNTIMES=all``, ``llvm-libgcc``
+is not included, and all runtimes targets must be manually listed.
+
+## Verifying your results
+
+This gets you a copy of libunwind with the libgcc symbols. You can verify this
+using ``readelf``.
+
+.. code-block:: bash
+
+  $ llvm-readelf -W --dyn-syms "${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.
+
+
+.. _supported platforms:
+
+Supported platforms
+===================
+
+llvm-libgcc currently supports the following target triples:
+
+* ``aarch64-*-*-*``
+* ``armv7a-*-*-gnueabihf``
+* ``i386-*-*-*``
+* ``x86_64-*-*-*``
+
+If you would like to support another triple (e.g. ``powerpc64-*-*-*``), you'll
+need to generate a new version script, and then edit ``lib/gcc_s.ver``.
+
+.. _Generating a new version script
+
+Generating a new version script
+-------------------------------
+
+To generate a new version script, we need to generate the list of symbols that
+exist in the set (``clang-builtins.a`` ∪ ``libunwind.a``) ∩ ``libgcc_s.so.1``.
+The prerequisites for generating a version script are a binaries for the three
+aforementioned libraries targeting your architecture (without having built
+llvm-libgcc).
+
+Once these libraries are in place, to generate a new version script, run the
+following command.
+
+.. code-block:: bash
+
+  /path/to/llvm-project
+  $ export ARCH=powerpc64
+  $ llvm/tools/llvm-libgcc/generate_version_script.py       \
+      --compiler_rt=/path/to/libclang_rt.builtins-${ARCH}.a \
+      --libunwind=/path/to/libunwind.a                      \
+      --libgcc_s=/path/to/libgcc_s.so.1                     \
+      --output=${ARCH}
+
+This will generate a new version script a la
+``/path/to/llvm-project/llvm/tools/llvm-libgcc/gcc_s-${ARCH}.ver``, which we use
+in the next section.
+
+.. _Editing ``lib/gcc_s.ver``
+
+Editing ``lib/gcc_s.ver``
+-------------------------
+
+Our freshly generated version script is unique to the specific architecture that
+it was generated for, but a lot of the symbols are shared among many platforms.
+As such, we don't check in unique version scripts, but rather have a single
+version script that's run through the C preprocessor to prune symbols we won't
+be using in ``lib/gcc_s.ver``.
+
+Working out which symbols are common is largely a manual process at the moment,
+because some symbols may be shared across different architectures, but not in
+the same versions of libgcc. As such, a symbol appearing in ``lib/gcc_s.ver``
+doesn't guarantee that the symbol is available for our new architecture: we need
+to verify that the versions are the same, and if they're not, add the symbol to
+the new version section, with the appropriate include guards.
+
+There are a few macros that aim to improve readability.
+
+* ``ARM_GNUEABIHF``, which targets exactly ``arm-*-*-gnueabihf``.
+* ``GLOBAL_X86``, which should be used to target both x86 and x86_64, regardless
+  of the triple.
+* ``GLOBAL_32BIT``, which is be used to target 32-bit platforms.
+* ``GLOBAL_64BIT``, which is be used to target 64-bit platforms.

llvm-libgcc/generate_version_script.py

+#!/usr/bin/env python3
+
+# Generates a version script for an architecture so that it can be incorporated
+# into gcc_s.ver.
+
+from collections import defaultdict
+from itertools import chain
+import argparse, subprocess, sys, os
+
+
+def split_suffix(symbol):
+    """
+    Splits a symbol such as `__gttf2@GCC_3.0` into a triple representing its
+    function name (__gttf2), version name (GCC_3.0), and version number (300).
+
+    The version number acts as a priority. Since earlier versions are more
+    accessible and are likely to be used more, the lower the number is, the higher
+    its priortiy. A symbol that has a '@@' instead of '@' has been designated by
+    the linker as the default symbol, and is awarded a priority of -1.
+    """
+    if '@' not in symbol:
+        return None
+    data = [i for i in filter(lambda s: s, symbol.split('@'))]
+    _, version = data[-1].split('_')
+    version = version.replace('.', '')
+    priority = -1 if '@@' in symbol else int(version + '0' *
+                                             (3 - len(version)))
+    return data[0], data[1], priority
+
+
+def invert_mapping(symbol_map):
+    """Transforms a map from Key->Value to Value->Key."""
+    store = defaultdict(list)
+    for symbol, (version, _) in symbol_map.items():
+        store[version].append(symbol)
+    result = []
+    for k, v in store.items():
+        v.sort()
+        result.append((k, v))
+    result.sort(key=lambda x: x[0])
+    return result
+
+
+def intersection(llvm, gcc):
+    """
+  Finds the intersection between the symbols extracted from compiler-rt.a/libunwind.a
+  and libgcc_s.so.1.
+  """
+    common_symbols = {}
+    for i in gcc:
+        suffix_triple = split_suffix(i)
+        if not suffix_triple:
+            continue
+
+        symbol, version_name, version_number = suffix_triple
+        if symbol in llvm:
+            if symbol not in common_symbols:
+                common_symbols[symbol] = (version_name, version_number)
+                continue
+            if version_number < common_symbols[symbol][1]:
+                common_symbols[symbol] = (version_name, version_number)
+    return invert_mapping(common_symbols)
+
+
+def find_function_names(path):
+    """
+    Runs readelf on a binary and reduces to only defined functions. Equivalent to
+    `llvm-readelf --wide ${path} | grep 'FUNC' | grep -v 'UND' | awk '{print $8}'`.
+    """
+    result = subprocess.run(args=['llvm-readelf', '-su', path],
+                            capture_output=True)
+
+    if result.returncode != 0:
+        print(result.stderr.decode('utf-8'), file=sys.stderr)
+        sys.exit(1)
+
+    stdout = result.stdout.decode('utf-8')
+    stdout = filter(lambda x: 'FUNC' in x and 'UND' not in x,
+                    stdout.split('\n'))
+    stdout = chain(
+        map(lambda x: filter(None, x), (i.split(' ') for i in stdout)))
+
+    return [list(i)[7] for i in stdout]
+
+
+def to_file(versioned_symbols):
+    path = f'{os.path.dirname(os.path.realpath(__file__))}/new-gcc_s-symbols'
+    with open(path, 'w') as f:
+        f.write('Do not check this version script in: you should instead work '
+                'out which symbols are missing in `lib/gcc_s.ver` and then '
+                'integrate them into `lib/gcc_s.ver`. For more information, '
+                'please see `doc/LLVMLibgcc.rst`.\n')
+        for version, symbols in versioned_symbols:
+            f.write(f'{version} {{\n')
+            for i in symbols:
+                f.write(f'  {i};\n')
+            f.write('};\n\n')
+
+
+def read_args():
+    parser = argparse.ArgumentParser()
+    parser.add_argument('--compiler_rt',
+                        type=str,
+                        help='Path to `libclang_rt.builtins-${ARCH}.a`.',
+                        required=True)
+    parser.add_argument('--libunwind',
+                        type=str,
+                        help='Path to `libunwind.a`.',
+                        required=True)
+    parser.add_argument(
+        '--libgcc_s',
+        type=str,
+        help=
+        'Path to `libgcc_s.so.1`. Note that unlike the other two arguments, this is a dynamic library.',
+        required=True)
+    return parser.parse_args()
+
+
+def main():
+    args = read_args()
+    llvm = find_function_names(args.compiler_rt) + find_function_names(
+        args.libunwind)
+    gcc = find_function_names(args.libgcc_s)
+    versioned_symbols = intersection(llvm, gcc)
+    # TODO(cjdb): work out a way to integrate new symbols in with the existing
+    #             ones
+    to_file(versioned_symbols)
+
+
+if __name__ == '__main__':
+    main()

llvm-libgcc/lib/CMakeLists.txt

+include(CheckLibraryExists)
+include(GNUInstallDirs)
+
+string(REPLACE "-Wl,-z,defs" "" CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS}")
+
+add_custom_target(gcc_s_ver ALL DEPENDS "${CMAKE_CURRENT_BINARY_DIR}/gcc_s.ver")
+set(LLVM_LIBGCC_GCC_S_VER "${CMAKE_CURRENT_BINARY_DIR}/gcc_s.ver")
+
+add_custom_target(gcc_s.ver ALL
+  DEPENDS "${CMAKE_CURRENT_SOURCE_DIR}/gcc_s.ver"
+  COMMAND
+    "${CMAKE_C_COMPILER}"
+    "-E"
+    "-xc" "${CMAKE_CURRENT_SOURCE_DIR}/gcc_s.ver"
+    "-o" "${CMAKE_CURRENT_BINARY_DIR}/gcc_s.ver"
+)
+set_target_properties(gcc_s.ver PROPERTIES
+  OUTPUT_PATH "${CMAKE_CURRENT_BINARY_DIR}/gcc_s.ver")
+
+add_library(libgcc_s SHARED blank.c)
+add_dependencies(libgcc_s gcc_s_ver)
+set_target_properties(libgcc_s
+  PROPERTIES
+    LINKER_LANGUAGE C
+    OUTPUT_NAME "unwind"
+    VERSION "1.0"
+    SOVERSION "1"
+    POSITION_INDEPENDENT_CODE ON)
+string(REGEX MATCH "[^-]+" LLVM_LIBGCC_TARGET_ARCH ${CMAKE_C_COMPILER_TARGET})
+target_link_libraries(libgcc_s PRIVATE
+  $<TARGET_OBJECTS:unwind_static>
+  $<TARGET_OBJECTS:clang_rt.builtins-${LLVM_LIBGCC_TARGET_ARCH}>
+)
+target_link_options(libgcc_s PRIVATE
+  -nostdlib
+  -Wl,--version-script,$<TARGET_PROPERTY:gcc_s.ver,OUTPUT_PATH>)
+
+check_library_exists(m sin "" LLVM_LIBGCC_HAS_LIBM)
+target_link_libraries(libgcc_s PRIVATE
+  $<$<BOOL:LLVM_LIBGCC_HAS_LIBM>:m>
+  c
+)
+
+get_filename_component(LLVM_LIBGCC_LIBUNWIND_STATIC_ROOT "${CMAKE_INSTALL_PREFIX}/${LIBUNWIND_INSTALL_LIBRARY_DIR}" ABSOLUTE)
+#string(REPLACE "${CMAKE_INSTALL_FULL_LIBDIR}/" "" LLVM_LIBGCC_LIBUNWIND_STATIC_ROOT "${LLVM_LIBGCC_LIBUNWIND_STATIC_ROOT}")
+
+install(TARGETS libgcc_s
+        LIBRARY DESTINATION "${LLVM_LIBGCC_LIBUNWIND_STATIC_ROOT}" COMPONENT unwind
+        ARCHIVE DESTINATION "${LLVM_LIBGCC_LIBUNWIND_STATIC_ROOT}" COMPONENT unwind
+        RUNTIME DESTINATION bin COMPONENT unwind)
+
+get_compiler_rt_install_dir(${LLVM_LIBGCC_TARGET_ARCH} install_dir_builtins)
+string(REGEX REPLACE "^lib/" "" install_dir_builtins "${install_dir_builtins}")
+string(FIND "${install_dir_builtins}" "clang" install_path_contains_triple)
+if(install_path_contains_triple EQUAL -1)
+  set(builtins_suffix "-${LLVM_LIBGCC_TARGET_ARCH}")
+else()
+  string(PREPEND install_dir_builtins "../")
+endif()
+install(CODE "execute_process(
+                COMMAND \"\${CMAKE_COMMAND}\" -E
+                create_symlink ${install_dir_builtins}/libclang_rt.builtins${builtins_suffix}.a libgcc.a
+                WORKING_DIRECTORY \"\$ENV{DESTDIR}${LLVM_LIBGCC_LIBUNWIND_STATIC_ROOT}\")"
+        COMPONENT unwind)
+
+install(CODE "execute_process(
+                COMMAND \"\${CMAKE_COMMAND}\" -E
+                create_symlink libunwind.a libgcc_eh.a
+                WORKING_DIRECTORY \"\$ENV{DESTDIR}${LLVM_LIBGCC_LIBUNWIND_STATIC_ROOT}\")"
+        COMPONENT unwind)
+install(CODE "execute_process(
+               COMMAND \"\${CMAKE_COMMAND}\" -E
+               create_symlink libunwind.so libgcc_s.so.1.0
+               WORKING_DIRECTORY \"\$ENV{DESTDIR}${LLVM_LIBGCC_LIBUNWIND_STATIC_ROOT}\")"
+        COMPONENT unwind)
+install(CODE "execute_process(
+                COMMAND \"\${CMAKE_COMMAND}\" -E
+                create_symlink libgcc_s.so.1.0 libgcc_s.so.1
+                WORKING_DIRECTORY \"\$ENV{DESTDIR}${LLVM_LIBGCC_LIBUNWIND_STATIC_ROOT}\")"
+        COMPONENT unwind)
+install(CODE "execute_process(
+                COMMAND \"\${CMAKE_COMMAND}\" -E
+                create_symlink libgcc_s.so.1 libgcc_s.so
+                WORKING_DIRECTORY \"\$ENV{DESTDIR}${LLVM_LIBGCC_LIBUNWIND_STATIC_ROOT}\")"
+        COMPONENT unwind)

llvm-libgcc/lib/gcc_s.ver

+// Detect if we're using arm-*-*-gnueabihf
+#if defined(__arm__) && \
+    defined(__ARM_ARCH_7A__) && defined(__ARM_EABI__) && \
+    defined(__ARM_FP) && (__ARM_FP >= 0x04)
+  #define ARM_GNUEABIHF
+#endif
+
+#if !defined(__x86_64__)  && \
+    !defined(__aarch64__) && \
+    !defined(__i386__)    && \
+    !defined(ARM_GNUEABIHF)
+  #error The only platforms that are currently supported are x86_64, i386, arm-gnueabihf, and aarch64.
+#endif
+
+#if defined(__x86_64__) || defined(__i386__)
+  #define GLOBAL_X86
+#endif
+
+#if __SIZEOF_POINTER__ >= 8
+  #define GLOBAL_64BIT
+#else
+  #define GLOBAL_32BIT
+#endif
+
+GCC_3.0 {
+  __absvdi2;    __absvsi2;    __addvdi3; __addvsi3; __clear_cache; __ffsdi2;
+  __fixunsdfdi; __fixunssfdi; __mulvdi3; __mulvsi3; __negvdi2;     __negvsi2;
+  __subvdi3;    __subvsi3;
+  _Unwind_DeleteException;
+  _Unwind_ForcedUnwind;
+  _Unwind_GetDataRelBase;
+  _Unwind_GetLanguageSpecificData;
+  _Unwind_GetRegionStart;
+  _Unwind_GetTextRelBase;
+  _Unwind_RaiseException;
+  _Unwind_Resume;
+};
+
+GCC_3.3   { _Unwind_GetCFA; _Unwind_Resume_or_Rethrow;                    };
+GCC_3.3.1 { __gcc_personality_v0;                                         };
+GCC_3.4   { __clzdi2; __ctzdi2; __paritydi2; __popcountdi2;               };
+GCC_3.4.2 { __enable_execute_stack;                                       };
+GCC_4.0.0 { __divdc3; __divsc3; __muldc3; __mulsc3; __powidf2; __powisf2; };
+GCC_4.3.0 { __bswapdi2; __bswapsi2; __emutls_get_address;                 };
+
+#if defined(GLOBAL_32BIT)
+  GCC_3.0 {
+    __ashldi3;    __ashrdi3;   __cmpdi2;    __fixdfdi; __fixsfdi; __fixunsdfsi;
+    __fixunssfsi; __floatdidf; __floatdisf; __lshrdi3; __muldi3;  __negdi2;
+    __ucmpdi2;    __udivmoddi4;
+  };
+
+  GCC_3.4   { __clzsi2;      __ctzsi2;      __paritysi2; __popcountsi2; };
+  GCC_4.2.0 { __floatundidf; __floatundisf;                             };
+  GCC_4.3.0 { __ffssi2;                                                 };
+  GCC_7.0.0 { __divmoddi4;                                              };
+  GLIBC_2.0 { __divdi3;     __moddi3;       __udivdi3; __umoddi3;       };
+#elif defined(GLOBAL_64BIT)
+  GCC_3.0 {
+    __ashlti3; __ashrti3;    __cmpti2;     __divti3;  __ffsti2;  __fixdfti;
+    __fixsfti; __fixunssfti; __floattidf;  __lshrti3; __modti3;  __multi3;
+    __negti2;  __ucmpti2;    __udivmodti4; __udivti3; __umodti3; __fixunsdfti;
+    __floattisf;
+  };
+
+  GCC_3.4   { __clzti2;      __ctzti2;  __parityti2; __popcountti2;           };
+  GCC_3.4.4 { __absvti2;     __addvti3; __mulvti3;   __negvti2;    __subvti3; };
+  GCC_4.2.0 { __floatuntidf; __floatuntisf;                                   };
+  GCC_7.0.0 { __divmodti4;                                                    };
+#endif
+
+#if defined(GLOBAL_X86)
+  GCC_3.0 {
+    __deregister_frame_info_bases; __fixunsxfdi; __register_frame_info_bases;
+    __register_frame_info_table_bases;
+  };
+
+  GCC_4.0.0 { __divxc3; __mulxc3; __powixf2; };
+  GCC_4.8.0 { __cpu_indicator_init;          };
+#endif
+
+#if !defined(ARM_GNUEABIHF)
+  GCC_3.0 {
+    _Unwind_Find_FDE; _Unwind_GetGR; _Unwind_GetIP; _Unwind_SetGR; _Unwind_SetIP;
+  };
+
+  GCC_3.3   { _Unwind_Backtrace; _Unwind_FindEnclosingFunction; };
+  GCC_4.2.0 { _Unwind_GetIPInfo; };
+#else // defined(ARM_GNUEABIHF)
+  GCC_3.0 {
+    __adddf3;  __addsf3;      __divdf3;  __divsf3;    __divsi3;    __eqdf2;
+    __eqsf2;   __extendsfdf2; __fixdfsi; __fixsfsi;   __floatsidf; __floatsisf;
+    __gedf2;   __gesf2;       __gtdf2;   __gtsf2;     __ledf2;     __lesf2;
+    __ltdf2;   __ltsf2;       __modsi3;  __muldf3;    __mulsf3;    __nedf2;
+    __negdf2;  __negsf2;      __nesf2;   __subdf3;    __subsf3;    __truncdfsf2;
+    __udivsi3; __umodsi3;
+  };
+
+  GCC_3.3.4 { __unorddf2; __unordsf2; };
+
+  GCC_3.5 {
+    __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;
+    _Unwind_Complete;
+    _Unwind_VRS_Get;
+    _Unwind_VRS_Pop;
+    _Unwind_VRS_Set;
+  };
+
+  GCC_4.2.0 { __floatunsidf; __floatunsisf; };
+  GCC_4.3.0 { _Unwind_Backtrace;            };
+#endif
+
+#if defined(__aarch64__)
+  GCC_3.0 {
+    __addtf3;     __divtf3;     __eqtf2;     __extenddftf2; __extendsftf2;
+    __fixtfdi;    __fixtfsi;    __fixtfti;   __fixunstfdi;  __fixunstfsi;
+    __fixunstfti; __floatditf;  __floatsitf; __floattitf;   __getf2;
+    __gttf2;      __letf2;      __lttf2;     __multf3;      __netf2;
+    __subtf3;     __trunctfdf2; __trunctfsf2;
+  };
+
+  GCC_4.0.0 { __powitf2;     __divtc3;      __multc3; };
+  GCC_4.2.0 { __floatunditf; __floatunsitf; __floatuntitf; };
+  GCC_4.5.0 { __unordtf2; };
+#endif
+
+#if defined(__aarch64__) || defined(__i386__)
+  GLIBC_2.0 { __deregister_frame; __register_frame; };
+#endif
+
+#if defined(__i386__)
+  GCC_3.0   { __fixunsxfsi; __fixxfdi; __floatdixf; };
+  GCC_4.2.0 { __floatundixf; };
+
+  GLIBC_2.0 {
+    __register_frame_info; __register_frame_info_table; __register_frame_table;
+    __deregister_frame_info;
+  };
+#endif
+
+#if defined(__x86_64__)
+  GCC_3.0 {
+    __register_frame_info; __register_frame_info_table; __register_frame_table;
+    __deregister_frame;    __deregister_frame_info;     __register_frame;
+    __fixunsxfti;          __fixxfti;                   __floattixf;
+  };
+
+  GCC_4.2.0 { __floatuntixf; };
+  GCC_4.3.0 { __divtc3; __multc3; };
+#endif

runtimes/CMakeLists.txt

 if(LLVM_INCLUDE_TESTS)
   set(LIT_ARGS_DEFAULT "-sv --show-xfail --show-unsupported")
   if (MSVC OR XCODE)
     set(LIT_ARGS_DEFAULT "${LIT_ARGS_DEFAULT} --no-progress-bar")
   endif()
   set(LLVM_LIT_ARGS "${LIT_ARGS_DEFAULT}" CACHE STRING "Default options for lit")
 endif()
 
+# llvm-libgcc incorporates both compiler-rt and libunwind as subprojects with very
+# specific flags, which causes clashes when they're independently built too.
+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()
+
 # We do this in two loops so that HAVE_* is set for each runtime before the
 # other runtimes are added.
 foreach(entry ${runtimes})
   get_filename_component(projName ${entry} NAME)
 
   # Between each sub-project we want to cache and clear the LIT properties
   set_property(GLOBAL PROPERTY LLVM_LIT_TESTSUITES)
   set_property(GLOBAL PROPERTY LLVM_LIT_PARAMS)
   set_property(GLOBAL PROPERTY LLVM_LIT_DEPENDS)
   set_property(GLOBAL PROPERTY LLVM_LIT_EXTRA_ARGS)