[compiler-rt][CMake] Properly set COMPILER_RT_HAS_LLD

[aeubanks]

Summary

LLVM_TOOL_LLD_BUILD is a relic of the pre-monorepo times. This causes us to never set COMPILER_RT_HAS_LLD.

Instead, set it from the runtimes build if lld is being built and lld is used as the compiler-rt linker.

Mark a test that requires libstdc++ as requiring Android, as other platforms may not have a libstdc++ lying around.

[aeubanks]

I'm not if lld will always be built before invoking the compiler-rt sub-cmake

[aeubanks]

hmm looks like some tests are failing because they're using a system lld, should this only be set if we're building lld?

[MaskRay]

It seems reasonable that COMPILER_RT_HAS_LLD is only set to true when we build lld in LLVM_ENABLE_PROJECTS builds or lld is available in a runtimes build.
I.e. don't consider COMPILER_RT_HAS_LLD true in LLVM_ENABLE_PROJECTS builds when lld comes from the system.

[phosek]

In D144660#4157423, @MaskRay wrote:

It seems reasonable that COMPILER_RT_HAS_LLD is only set to true when we build lld in LLVM_ENABLE_PROJECTS builds or lld is available in a runtimes build.
I.e. don't consider COMPILER_RT_HAS_LLD true in LLVM_ENABLE_PROJECTS builds when lld comes from the system.

I agree, with system LLD we have no control over the version.

[aeubanks]

how would you detect if a built lld is available in a runtimes build?

[aeubanks]

update

[barannikov88]

Is this correct? If lld is listed in LLVM_ENABLE_PROJECTS it does not necessarily
mean that it can target all architectures for which the libraries are being built.
Perhaps it should instead check RUNTIMES_<triple>_LLVM_ENABLE_LLD or something like that?

[aeubanks]

also check if we're using lld

[aeubanks]

ping

[aeubanks]

ping

[MaskRay]

A bit of rubber stamp as I don't understand CMake well enough...

[barannikov88]

This still does not look right to me. The fact that lld is on the LLVM_ENABLE_PROJECT list does not mean that it is used for linking runtime libraries.
I add lld to the list because I use it to link x86 binaries, but I build runtimes for a different architecture and use a different linker for that.
This should be a per-target check somehow. AIUI it should check some RUNTIME_<triple>_ variable, presumably RUNTIME_<triple>_LLVM_USE_LINKER or RUNTIME_<triple>_LLVM_ENABLE_LLD.

[aeubanks]

In D144660#4381808, @barannikov88 wrote:

This still does not look right to me. The fact that lld is on the LLVM_ENABLE_PROJECT list does not mean that it is used for linking runtime libraries.
I add lld to the list because I use it to link x86 binaries, but I build runtimes for a different architecture and use a different linker for that.
This should be a per-target check somehow. AIUI it should check some RUNTIME_<triple>_ variable, presumably RUNTIME_<triple>_LLVM_USE_LINKER or RUNTIME_<triple>_LLVM_ENABLE_LLD.

the compiler-rt/CMakeLists.txt change does check LLVM_USE_LINKER. the RUNTIME_*_LLVM_USE_LINKER gets translated to LLVM_USE_LINKER by the time compiler-rt/CMakeLists.txt is invoked

[barannikov88]

In D144660#4381813, @aeubanks wrote:

In D144660#4381808, @barannikov88 wrote:

This still does not look right to me. The fact that lld is on the LLVM_ENABLE_PROJECT list does not mean that it is used for linking runtime libraries.
I add lld to the list because I use it to link x86 binaries, but I build runtimes for a different architecture and use a different linker for that.
This should be a per-target check somehow. AIUI it should check some RUNTIME_<triple>_ variable, presumably RUNTIME_<triple>_LLVM_USE_LINKER or RUNTIME_<triple>_LLVM_ENABLE_LLD.

the compiler-rt/CMakeLists.txt change does check LLVM_USE_LINKER. the RUNTIME_*_LLVM_USE_LINKER gets translated to LLVM_USE_LINKER by the time compiler-rt/CMakeLists.txt is invoked

Right, thanks. Then I have no objection here.

I'm confused about these lines:

llvm/runtimes/CMakeLists.txt:250: PASSTHROUGH_PREFIXES LLVM_ENABLE_RUNTIMES
llvm/runtimes/CMakeLists.txt:251: LLVM_USE_LINKER
llvm/runtimes/CMakeLists.txt:326: list(APPEND ${name}_extra_args -DLLVM_USE_LINKER=${LLVM_USE_LINKER})

But I guess this is a different story…

[phosek]

I missed the latest revision so I apologize about the late comment. I'm fine with this change but I'm worried whether this strategy is going to scale. If we need a similar variable in other runtimes, are we going to introduce more variables like ${name}_HAS_TRUNK_LLD=TRUE, etc? I think we need a better long-term strategy that doesn't require special casing individual runtimes. Perhaps we could just passthrough LLVM_ENABLE_PROJECTS into the runtimes build and then do the "lld" IN_LIST LLVM_ENABLE_PROJECTS check in individual runtimes?

[aeubanks]

In D144660#4384688, @phosek wrote:

I missed the latest revision so I apologize about the late comment. I'm fine with this change but I'm worried whether this strategy is going to scale. If we need a similar variable in other runtimes, are we going to introduce more variables like ${name}_HAS_TRUNK_LLD=TRUE, etc? I think we need a better long-term strategy that doesn't require special casing individual runtimes. Perhaps we could just passthrough LLVM_ENABLE_PROJECTS into the runtimes build and then do the "lld" IN_LIST LLVM_ENABLE_PROJECTS check in individual runtimes?

passing through LLVM_ENABLE_PROJECTS seems good, I'll look at that

[haowei]

Hi, this patch breaks runtime tests HWAddressSanitizer-x86_64 :: TestCases/sizes.cpp , Error message:

Script:
--
: 'RUN: at line 3';      /b/s/w/ir/x/w/staging/llvm_build/./bin/clang  --driver-mode=g++   -Wthread-safety -Wthread-safety-reference -Wthread-safety-beta   -gline-tables-only -fsanitize=hwaddress -fuse-ld=lld -fsanitize-hwaddress-experimental-aliasing -mllvm -hwasan-generate-tags-with-calls=1 -mllvm -hwasan-globals -mllvm -hwasan-use-short-granules -mllvm -hwasan-instrument-landing-pads=0 -mllvm -hwasan-instrument-personality-functions /b/s/w/ir/x/w/llvm-llvm-project/compiler-rt/test/hwasan/TestCases/sizes.cpp -nostdlib++ -lstdc++ -o /b/s/w/ir/x/w/staging/llvm_build/runtimes/runtimes-x86_64-unknown-linux-gnu-bins/compiler-rt/test/hwasan/X86_64/TestCases/Output/sizes.cpp.tmp
: 'RUN: at line 4';   env HWASAN_OPTIONS=disable_allocator_tagging=1:random_tags=0:fail_without_syscall_abi=0:allocator_may_return_null=0 not  /b/s/w/ir/x/w/staging/llvm_build/runtimes/runtimes-x86_64-unknown-linux-gnu-bins/compiler-rt/test/hwasan/X86_64/TestCases/Output/sizes.cpp.tmp malloc 2>&1          | FileCheck /b/s/w/ir/x/w/llvm-llvm-project/compiler-rt/test/hwasan/TestCases/sizes.cpp --check-prefix=CHECK-max
: 'RUN: at line 5';   env HWASAN_OPTIONS=disable_allocator_tagging=1:random_tags=0:fail_without_syscall_abi=0:allocator_may_return_null=1      /b/s/w/ir/x/w/staging/llvm_build/runtimes/runtimes-x86_64-unknown-linux-gnu-bins/compiler-rt/test/hwasan/X86_64/TestCases/Output/sizes.cpp.tmp malloc 2>&1
: 'RUN: at line 6';   env HWASAN_OPTIONS=disable_allocator_tagging=1:random_tags=0:fail_without_syscall_abi=0:allocator_may_return_null=0 not  /b/s/w/ir/x/w/staging/llvm_build/runtimes/runtimes-x86_64-unknown-linux-gnu-bins/compiler-rt/test/hwasan/X86_64/TestCases/Output/sizes.cpp.tmp malloc max 2>&1      | FileCheck /b/s/w/ir/x/w/llvm-llvm-project/compiler-rt/test/hwasan/TestCases/sizes.cpp --check-prefix=CHECK-max
: 'RUN: at line 7';   env HWASAN_OPTIONS=disable_allocator_tagging=1:random_tags=0:fail_without_syscall_abi=0:allocator_may_return_null=1      /b/s/w/ir/x/w/staging/llvm_build/runtimes/runtimes-x86_64-unknown-linux-gnu-bins/compiler-rt/test/hwasan/X86_64/TestCases/Output/sizes.cpp.tmp malloc max 2>&1
: 'RUN: at line 8';   env HWASAN_OPTIONS=disable_allocator_tagging=1:random_tags=0:fail_without_syscall_abi=0:allocator_may_return_null=0 not  /b/s/w/ir/x/w/staging/llvm_build/runtimes/runtimes-x86_64-unknown-linux-gnu-bins/compiler-rt/test/hwasan/X86_64/TestCases/Output/sizes.cpp.tmp calloc 2>&1          | FileCheck /b/s/w/ir/x/w/llvm-llvm-project/compiler-rt/test/hwasan/TestCases/sizes.cpp --check-prefix=CHECK-calloc
: 'RUN: at line 9';   env HWASAN_OPTIONS=disable_allocator_tagging=1:random_tags=0:fail_without_syscall_abi=0:allocator_may_return_null=1      /b/s/w/ir/x/w/staging/llvm_build/runtimes/runtimes-x86_64-unknown-linux-gnu-bins/compiler-rt/test/hwasan/X86_64/TestCases/Output/sizes.cpp.tmp calloc 2>&1
: 'RUN: at line 10';   env HWASAN_OPTIONS=disable_allocator_tagging=1:random_tags=0:fail_without_syscall_abi=0:allocator_may_return_null=0 not  /b/s/w/ir/x/w/staging/llvm_build/runtimes/runtimes-x86_64-unknown-linux-gnu-bins/compiler-rt/test/hwasan/X86_64/TestCases/Output/sizes.cpp.tmp reallocarray 2>&1    | FileCheck /b/s/w/ir/x/w/llvm-llvm-project/compiler-rt/test/hwasan/TestCases/sizes.cpp --check-prefix=CHECK-reallocarray
: 'RUN: at line 11';   env HWASAN_OPTIONS=disable_allocator_tagging=1:random_tags=0:fail_without_syscall_abi=0:allocator_may_return_null=1      /b/s/w/ir/x/w/staging/llvm_build/runtimes/runtimes-x86_64-unknown-linux-gnu-bins/compiler-rt/test/hwasan/X86_64/TestCases/Output/sizes.cpp.tmp reallocarray 2>&1
: 'RUN: at line 12';   env HWASAN_OPTIONS=disable_allocator_tagging=1:random_tags=0:fail_without_syscall_abi=0:allocator_may_return_null=0 not  /b/s/w/ir/x/w/staging/llvm_build/runtimes/runtimes-x86_64-unknown-linux-gnu-bins/compiler-rt/test/hwasan/X86_64/TestCases/Output/sizes.cpp.tmp new 2>&1             | FileCheck /b/s/w/ir/x/w/llvm-llvm-project/compiler-rt/test/hwasan/TestCases/sizes.cpp --check-prefix=CHECK-max
: 'RUN: at line 13';   env HWASAN_OPTIONS=disable_allocator_tagging=1:random_tags=0:fail_without_syscall_abi=0:allocator_may_return_null=1 not  /b/s/w/ir/x/w/staging/llvm_build/runtimes/runtimes-x86_64-unknown-linux-gnu-bins/compiler-rt/test/hwasan/X86_64/TestCases/Output/sizes.cpp.tmp new 2>&1             | FileCheck /b/s/w/ir/x/w/llvm-llvm-project/compiler-rt/test/hwasan/TestCases/sizes.cpp --check-prefix=CHECK-oom
: 'RUN: at line 14';   env HWASAN_OPTIONS=disable_allocator_tagging=1:random_tags=0:fail_without_syscall_abi=0:allocator_may_return_null=0 not  /b/s/w/ir/x/w/staging/llvm_build/runtimes/runtimes-x86_64-unknown-linux-gnu-bins/compiler-rt/test/hwasan/X86_64/TestCases/Output/sizes.cpp.tmp new max 2>&1         | FileCheck /b/s/w/ir/x/w/llvm-llvm-project/compiler-rt/test/hwasan/TestCases/sizes.cpp --check-prefix=CHECK-max
: 'RUN: at line 15';   env HWASAN_OPTIONS=disable_allocator_tagging=1:random_tags=0:fail_without_syscall_abi=0:allocator_may_return_null=1 not  /b/s/w/ir/x/w/staging/llvm_build/runtimes/runtimes-x86_64-unknown-linux-gnu-bins/compiler-rt/test/hwasan/X86_64/TestCases/Output/sizes.cpp.tmp new max 2>&1         | FileCheck /b/s/w/ir/x/w/llvm-llvm-project/compiler-rt/test/hwasan/TestCases/sizes.cpp --check-prefix=CHECK-oom
: 'RUN: at line 16';   env HWASAN_OPTIONS=disable_allocator_tagging=1:random_tags=0:fail_without_syscall_abi=0:allocator_may_return_null=0 not  /b/s/w/ir/x/w/staging/llvm_build/runtimes/runtimes-x86_64-unknown-linux-gnu-bins/compiler-rt/test/hwasan/X86_64/TestCases/Output/sizes.cpp.tmp new-nothrow 2>&1     | FileCheck /b/s/w/ir/x/w/llvm-llvm-project/compiler-rt/test/hwasan/TestCases/sizes.cpp --check-prefix=CHECK-max
: 'RUN: at line 17';   env HWASAN_OPTIONS=disable_allocator_tagging=1:random_tags=0:fail_without_syscall_abi=0:allocator_may_return_null=1      /b/s/w/ir/x/w/staging/llvm_build/runtimes/runtimes-x86_64-unknown-linux-gnu-bins/compiler-rt/test/hwasan/X86_64/TestCases/Output/sizes.cpp.tmp new-nothrow 2>&1
: 'RUN: at line 18';   env HWASAN_OPTIONS=disable_allocator_tagging=1:random_tags=0:fail_without_syscall_abi=0:allocator_may_return_null=0 not  /b/s/w/ir/x/w/staging/llvm_build/runtimes/runtimes-x86_64-unknown-linux-gnu-bins/compiler-rt/test/hwasan/X86_64/TestCases/Output/sizes.cpp.tmp new-nothrow max 2>&1 | FileCheck /b/s/w/ir/x/w/llvm-llvm-project/compiler-rt/test/hwasan/TestCases/sizes.cpp --check-prefix=CHECK-max
: 'RUN: at line 19';   env HWASAN_OPTIONS=disable_allocator_tagging=1:random_tags=0:fail_without_syscall_abi=0:allocator_may_return_null=1      /b/s/w/ir/x/w/staging/llvm_build/runtimes/runtimes-x86_64-unknown-linux-gnu-bins/compiler-rt/test/hwasan/X86_64/TestCases/Output/sizes.cpp.tmp new-nothrow max 2>&1
: 'RUN: at line 20';                                                    /b/s/w/ir/x/w/staging/llvm_build/runtimes/runtimes-x86_64-unknown-linux-gnu-bins/compiler-rt/test/hwasan/X86_64/TestCases/Output/sizes.cpp.tmp usable 2>&1
--
Exit Code: 1

Command Output (stderr):
--
ld.lld: error: unable to find library -lstdc++
clang: error: linker command failed with exit code 1 (use -v to see invocation)

--

I ran a test build without this change and it passed.
Could you look into this, and if it takes a while, could you revert this change please?

[aeubanks]

@haowei could you post the lld command before and after the patch? bin/llvm-lit -a runtimes/runtimes-bins/compiler-rt/test/hwasan/X86_64/TestCases/sizes.cpp

[haowei]

In D144660#4384939, @aeubanks wrote:

@haowei could you post the lld command before and after the patch? bin/llvm-lit -a runtimes/runtimes-bins/compiler-rt/test/hwasan/X86_64/TestCases/sizes.cpp

The test run with revert was conducted on a bot, I don't have shell access to manually ran any command nor do I have access to the build directory, sorry.

The task with your change reverted: https://luci-milo.appspot.com/raw/build/logs.chromium.org/fuchsia/led/haowei_google.com/44a1b91abf6fccb72bd3e88d382fb350d3647485d851446b6364cbe9008c9837/+/build.proto

The task failed with your change: https://ci.chromium.org/ui/p/fuchsia/builders/toolchain.ci/clang-linux-x64/b8779565760229543425/overview

I could manually verify it on my workstation and try digging into the lld invocation in this unit test. But it would take some time. If you prefer that, could you revert the change while we investigating the issue?

[aeubanks]

In D144660#4384688, @phosek wrote:

I missed the latest revision so I apologize about the late comment. I'm fine with this change but I'm worried whether this strategy is going to scale. If we need a similar variable in other runtimes, are we going to introduce more variables like ${name}_HAS_TRUNK_LLD=TRUE, etc? I think we need a better long-term strategy that doesn't require special casing individual runtimes. Perhaps we could just passthrough LLVM_ENABLE_PROJECTS into the runtimes build and then do the "lld" IN_LIST LLVM_ENABLE_PROJECTS check in individual runtimes?

passing through LLVM_ENABLE_PROJECTS gives me a bunch of

CMake Error at /usr/local/google/home/aeubanks/repos/llvm-project/llvm/cmake/modules/AddLLVM.cmake:1929 (add_dependencies):
  The dependency target "lld" of target "check-runtimes" does not exist.
Call Stack (most recent call first):
  /usr/local/google/home/aeubanks/repos/llvm-project/llvm/cmake/modules/AddLLVM.cmake:1969 (add_lit_target)
  CMakeLists.txt:252 (umbrella_lit_testsuite_end)

[aeubanks]

In D144660#4384963, @haowei wrote:

In D144660#4384939, @aeubanks wrote:

@haowei could you post the lld command before and after the patch? bin/llvm-lit -a runtimes/runtimes-bins/compiler-rt/test/hwasan/X86_64/TestCases/sizes.cpp

The test run with revert was conducted on a bot, I don't have shell access to manually ran any command nor do I have access to the build directory, sorry.

The task with your change reverted: https://luci-milo.appspot.com/raw/build/logs.chromium.org/fuchsia/led/haowei_google.com/44a1b91abf6fccb72bd3e88d382fb350d3647485d851446b6364cbe9008c9837/+/build.proto

The task failed with your change: https://ci.chromium.org/ui/p/fuchsia/builders/toolchain.ci/clang-linux-x64/b8779565760229543425/overview

I could manually verify it on my workstation and try digging into the lld invocation in this unit test. But it would take some time. If you prefer that, could you revert the change while we investigating the issue?

I've reverted for now. My guess is that most typical bots have libstdc++ lying around but yours doesn't? Although I have no idea why this change would affect that?

[haowei]

In D144660#4384982, @aeubanks wrote:

In D144660#4384963, @haowei wrote:

In D144660#4384939, @aeubanks wrote:

@haowei could you post the lld command before and after the patch? bin/llvm-lit -a runtimes/runtimes-bins/compiler-rt/test/hwasan/X86_64/TestCases/sizes.cpp

The test run with revert was conducted on a bot, I don't have shell access to manually ran any command nor do I have access to the build directory, sorry.

The task with your change reverted: https://luci-milo.appspot.com/raw/build/logs.chromium.org/fuchsia/led/haowei_google.com/44a1b91abf6fccb72bd3e88d382fb350d3647485d851446b6364cbe9008c9837/+/build.proto

The task failed with your change: https://ci.chromium.org/ui/p/fuchsia/builders/toolchain.ci/clang-linux-x64/b8779565760229543425/overview

I could manually verify it on my workstation and try digging into the lld invocation in this unit test. But it would take some time. If you prefer that, could you revert the change while we investigating the issue?

I've reverted for now. My guess is that most typical bots have libstdc++ lying around but yours doesn't? Although I have no idea why this change would affect that?

Yeah, the bot's doesn't have libc++ installed from system. It does have a sysroot prebuilt but everything ran from clang/llvm build should be self contained.

I will start a A/B build locally right away. But since my workstation has libstdc++, it probably won't reproduce the failure, but I can see what command line have changed.

[haowei]

I think I understood why your change trigger the failure on the bots, without your patch, this test is unsupported, see:

UNSUPPORTED: HWAddressSanitizer-x86_64 :: TestCases/sizes.cpp (1365 of 13292)

from log output: https://logs.chromium.org/logs/fuchsia/buildbucket/cr-buildbucket/8779557369614664945/+/u/clang/test/stdout

[aeubanks]

mark test as requiring android

[aeubanks]

update commit message

[aeubanks]

UNSUPPORTED: HWAddressSanitizer-x86_64 :: TestCases/sizes.cpp (1365 of 13292)

ah makes sense, compiler-rt/test/hwasan/lit.cfg.py does check for this

Yeah, the bot's doesn't have libc++ installed from system. It does have a sysroot prebuilt but everything ran from clang/llvm build should be self contained.

Did you mean libstdc++? IIUC compiler-rt tests will often compile with system headers. I think libstdc++ is typically expected to be on Linux bots. But I've marked that test as REQUIRES: android so it's more targeted.

[vitalybuka]

compiler-rt/CMakeLists.txt

740

What is LLVM_ENABLE_LLD?

[vitalybuka]

compiler-rt/CMakeLists.txt

740

Looks like it's covered

compiler-rt/test/hwasan/TestCases/sizes.cpp

22

Please add comment like:
FIXME: Allocation sizes adjusted to trigger errors on Android. Support general Linux.

compiler-rt/CMakeLists.txt

foreach(path IN ITEMS ${LLVM_MAIN_SRC_DIR}/projects/libcxxabi
                           ${LLVM_EXTERNAL_LIBCXXABI_SOURCE_DIR})
       if(IS_DIRECTORY ${path})
         set(COMPILER_RT_LIBCXXABI_PATH ${path})
         break()
       endif()
     endforeach()
   endif()
 endif()
 
-set(COMPILER_RT_LLD_PATH ${LLVM_MAIN_SRC_DIR}/tools/lld)
-if(EXISTS ${COMPILER_RT_LLD_PATH}/ AND LLVM_TOOL_LLD_BUILD)
+if(COMPILER_RT_HAS_TRUNK_LLD AND LLVM_USE_LINKER STREQUAL "lld")
   set(COMPILER_RT_HAS_LLD TRUE)
-else()
-  set(COMPILER_RT_LLD_PATH ${LLVM_MAIN_SRC_DIR}/../lld)
-  if(EXISTS ${COMPILER_RT_LLD_PATH}/ AND LLVM_TOOL_LLD_BUILD)
-    set(COMPILER_RT_HAS_LLD TRUE)
-  endif()
 endif()
 
 if(ANDROID)
   set(COMPILER_RT_HAS_LLD TRUE)
   set(COMPILER_RT_TEST_USE_LLD TRUE)
   append_list_if(COMPILER_RT_HAS_FUSE_LD_LLD_FLAG -fuse-ld=lld SANITIZER_COMMON_LINK_FLAGS)
   append_list_if(COMPILER_RT_HAS_LLD -fuse-ld=lld COMPILER_RT_UNITTEST_LINK_FLAGS)
 endif()

compiler-rt/test/hwasan/TestCases/sizes.cpp

 // RUN: %env_hwasan_opts=allocator_may_return_null=0 not %run %t new max 2>&1         | FileCheck %s --check-prefix=CHECK-max
 // RUN: %env_hwasan_opts=allocator_may_return_null=1 not %run %t new max 2>&1         | FileCheck %s --check-prefix=CHECK-oom
 // RUN: %env_hwasan_opts=allocator_may_return_null=0 not %run %t new-nothrow 2>&1     | FileCheck %s --check-prefix=CHECK-max
 // RUN: %env_hwasan_opts=allocator_may_return_null=1     %run %t new-nothrow 2>&1
 // RUN: %env_hwasan_opts=allocator_may_return_null=0 not %run %t new-nothrow max 2>&1 | FileCheck %s --check-prefix=CHECK-max
 // RUN: %env_hwasan_opts=allocator_may_return_null=1     %run %t new-nothrow max 2>&1
 // RUN:                                                 %run %t usable 2>&1
 
+// REQUIRES: android
+
 // Tests for various edge cases related to sizes, notably the maximum size the
 // allocator can allocate. Tests that an integer overflow in the parameters of
 // calloc is caught.
 
 #include <assert.h>
 #include <malloc.h>
 #include <stdlib.h>
 #include <string.h>

llvm/runtimes/CMakeLists.txt

function(runtime_default_target)
 
   if(LLVM_INCLUDE_TESTS)
     set_property(GLOBAL APPEND PROPERTY LLVM_ALL_LIT_TESTSUITES "@${LLVM_BINARY_DIR}/runtimes/runtimes-bins/lit.tests")
     list(APPEND test_targets runtimes-test-depends check-runtimes)
   endif()
 
   set_enable_per_target_runtime_dir()
 
+  if ("lld" IN_LIST LLVM_ENABLE_PROJECTS)
+    list(APPEND extra_args -DCOMPILER_RT_HAS_TRUNK_LLD=TRUE)
+  endif()
+
   llvm_ExternalProject_Add(runtimes
                            ${CMAKE_CURRENT_SOURCE_DIR}/../../runtimes
                            DEPENDS ${ARG_DEPENDS}
                            # Builtins were built separately above
                            CMAKE_ARGS -DCOMPILER_RT_BUILD_BUILTINS=Off
                                       -DLLVM_INCLUDE_TESTS=${LLVM_INCLUDE_TESTS}
                                       -DLLVM_DEFAULT_TARGET_TRIPLE=${LLVM_TARGET_TRIPLE}
                                       -DLLVM_ENABLE_PROJECTS_USED=${LLVM_ENABLE_PROJECTS_USED}
                                       -DLLVM_ENABLE_PER_TARGET_RUNTIME_DIR=${LLVM_ENABLE_PER_TARGET_RUNTIME_DIR}
                                       -DLLVM_BUILD_TOOLS=${LLVM_BUILD_TOOLS}
                                       -DCMAKE_C_COMPILER_WORKS=ON
                                       -DCMAKE_CXX_COMPILER_WORKS=ON
                                       -DCMAKE_ASM_COMPILER_WORKS=ON
                                       ${COMMON_CMAKE_ARGS}
                                       ${RUNTIMES_CMAKE_ARGS}
                                       ${ARG_CMAKE_ARGS}
+                                      ${extra_args}
                            PASSTHROUGH_PREFIXES LLVM_ENABLE_RUNTIMES
                                                 LLVM_USE_LINKER
                                                 ${ARG_PREFIXES}
                            EXTRA_TARGETS ${extra_targets}
                                          ${test_targets}
                                          ${SUB_COMPONENTS}
                                          ${SUB_CHECK_TARGETS}
                                          ${SUB_INSTALL_TARGETS}
foreach(variable_name ${variable_names})
         string(REPLACE ";" "|" new_value "${${variable_name}}")
         list(APPEND ${name}_extra_args "-D${new_name}=${new_value}")
       endif()
     endforeach()
   endforeach()
 
   set_enable_per_target_runtime_dir()
 
+  if ("lld" IN_LIST LLVM_ENABLE_PROJECTS)
+    list(APPEND ${name}_extra_args -DCOMPILER_RT_HAS_TRUNK_LLD=TRUE)
+  endif()
+
   llvm_ExternalProject_Add(runtimes-${name}
                            ${CMAKE_CURRENT_SOURCE_DIR}/../../runtimes
                            DEPENDS ${ARG_DEPENDS}
                            # Builtins were built separately above
                            CMAKE_ARGS -DCOMPILER_RT_BUILD_BUILTINS=OFF
                                       -DLLVM_INCLUDE_TESTS=${LLVM_INCLUDE_TESTS}
                                       -DLLVM_ENABLE_PROJECTS_USED=${LLVM_ENABLE_PROJECTS_USED}
                                       -DLLVM_ENABLE_PER_TARGET_RUNTIME_DIR=${LLVM_ENABLE_PER_TARGET_RUNTIME_DIR}