LGTM

Since you always include all three of //llvm/lib/Target/targets.gni, //llvm/lib/Target/targets_with_asm_parsers.gni, //llvm/lib/Target/targets_with_disassemblers.gni, why not just combine all of them into //llvm/lib/Target/targets.gni? If we ever need them separately and performance becomes an issue, we can split them later.

LGTM

This broke all our macOS builders:

llvm-lit: /b/s/w/ir/k/llvm-project/llvm/utils/lit/lit/TestingConfig.py:102: fatal: unable to parse config file '/b/s/w/ir/k/recipe_cleanup/clangh7IvHV/llvm_build_dir/tools/lld/test/lit.site.cfg.py', traceback: Traceback (most recent call last):
  File "/b/s/w/ir/k/llvm-project/llvm/utils/lit/lit/TestingConfig.py", line 89, in load_from_path
    exec(compile(data, path, 'exec'), cfg_globals, None)
  File "/b/s/w/ir/k/recipe_cleanup/clangh7IvHV/llvm_build_dir/tools/lld/test/lit.site.cfg.py", line 31, in <module>
    lit.llvm.initialize(lit_config, config)
  File "/b/s/w/ir/k/llvm-project/llvm/utils/lit/lit/llvm/__init__.py", line 9, in initialize
    llvm_config = config.LLVMConfig(lit_config, test_config)
  File "/b/s/w/ir/k/llvm-project/llvm/utils/lit/lit/llvm/config.py", line 51, in __init__
    if config.enable_shared:
AttributeError: TestingConfig instance has no attribute 'enable_shared'

The problem is that enable_shared isn't defined in lld's lit.site.cfg.py. Is it possible to either fix this or revert this change?

LGTM

One more thing, do you think it's reasonable to use llvm::sys::findProgramByName(Args[0])instead of Args[0] when creating the driver instance? One of the failure modes I ran into is the case where the generated compilation database would contain just the executable name, e.g. clang++. If you invoke that command, everything works as expected because driver resolves the binary to a full path, but when used with clangd, it'll fail because that resolution will never happen, the Dir/InstalledDir will be an empty path and attempt to resolve C++ library headers will end up with /../include/c++/v1 which is invalid.

In D63092#1536774, @sammccall wrote:

argv[0] does carry important information though, I think this will break a lot of things. It's... concerning that no tests broke.

For example, if it's clang or g++ or clang-cl then that affects how command lines are parsed (regardless of whether the path actually exists).

In D62695#1530338, @phosek wrote:

This seems to have introduced PR42129.

This seems to have introduced PR42129.

https://storage.googleapis.com/fuchsia-build/reproducer/fuzzer.tar.bz2 is the reproducer.

We're now getting a lot of STT_SECTION symbol should be defined warnings when building libFuzzer: https://logs.chromium.org/logs/fuchsia/buildbucket/cr-buildbucket.appspot.com/8911634509805270864/+/steps/clang/0/steps/build/0/stdout. The libFuzzer uses lld to produce a single relocatable file with libc++ linked in: https://github.com/llvm/llvm-project/blob/master/compiler-rt/lib/fuzzer/CMakeLists.txt#L132. I haven't yet figured out what's going on (the warning could be also a little more specific, e.g. which symbol and which section). Do you have any idea what's going on?

In D62622#1523269, @aprantl wrote:

I like LLVM_USE_RELATIVE_PATHS_IN_DEBUG_INFO.

I've tested this locally and it seems to be working fine, I'd like to land this to unbreak our bots.

In D62622#1522247, @aprantl wrote:

-DLLVM_USE_RELATIVE_PATHS is very generic sounding and might give a false impression. Is there a name that emphasizes that this affects the debug info of the built compiler?

Does anyone have any opinion on add_compile_flags_if_supported vs check_cxx_compiler_flag + append_if? If not I'm going to land this as is.

In D62090#1521187, @ldionne wrote:

It's not entirely clear to me that adding an option to control this is better than just doing it unconditionally. Have you run into a scenario where you didn't want to enable it (and if so, why?).

If that's "just in case", I'd suggest doing it unconditionally and adding an option later if a vendor wants to disable it.

LGTM

Alternative would be to avoid add_compile_flags_if_supported altogether and instead the combination of check_cxx_compiler_flag and append_if as is used in libunwind (https://github.com/llvm/llvm-project/blob/master/libunwind/CMakeLists.txt#L274). The advantage of the latter is that we could in theory have different config-ix.cmake files (e.g. pre-populated ones for the runtimes build).