Makes lld-link work in a non-MSVC shell by autodetecting MSVC toolchain. Also adds support for /winsysroot and a few other switches.
All this is done by refactoring to share code with clang-cl's existing support for the same.
Differential D118070
Make lld-link work in a non-MSVC shell pkasting on Jan 24 2022, 1:05 PM. Authored by
Details Makes lld-link work in a non-MSVC shell by autodetecting MSVC toolchain. Also adds support for /winsysroot and a few other switches. All this is done by refactoring to share code with clang-cl's existing support for the same.
Diff Detail Event TimelineComment Actions Very very cool. This needs a test. Maybe you just forgot to git add it? It'd be nice if the knowledge what the sysroot layout looks like (a Windows\ Kits/10/... dir, a VC/Tools/MSVC/*/ dir, optionally a DIA SDK dir) wasn't duplicated between here and clang. Could we pull that out into some common code in llvm/lib/Support and call that in both places?
Comment Actions Adds autodetection and full support for other clang-cl switches, but doesn't work: config->machine is not set this early, so it's always UNKNOWN. Comment Actions This looks super nice. Things that can still improve:
@mstorsjo, fyi.
Comment Actions Updated description.
Did what I think I could, see details in comments.
Added a few basic tests, please review.
Comment Actions Does it make sense to add a new platform library? LLVMPlatformWindows? LLVMWindows? LLVMWindowsTools? LLVMWindowsABI?
@pkasting Note, this patch makes the outcome non-deterministic when the auto-detection kicks in. We are stamping the command-line the .PDB file, see https://github.com/llvm/llvm-project/blob/main/lld/COFF/PDB.cpp#L1402 - and some live-code-patching tools rely on that to reproduce the link. It'd be nice if the detected paths are queued to config->argv, to ensure that we can emit a self-standing LLD cmd-line, a bit like what clang -cc1 does.
Comment Actions There is a precedent: llvm/lib/WindowsManifest. So having a library in llvm/lib/ seems fine. I do not know whether it makes sense to combine the Windows driver library with WindowsManifest. Comment Actions
You mean "non-deterministic" in "cmd.exe / local-computer dependent", yes? If so: There are enough flags that you can pass in to make the output deterministic if this is something you care about. (We care about determinism a lot over in chromium land!) I think the setup matches what we have in clang, right? Comment Actions I think this looks great. maskray, I kind of see where you're coming from. And I'm _very_ sympathetic to keeping Support small(er). On the other hand, this is a single file that doesn't require any additional dependencies on libs (…I think), so a dedicated library feels a bit overkill to me, maybe. (Are there any "when not to put your stuff in Support" guidelines anywhere?)
Comment Actions I think I still feel that having this in LLVMSupport is strange, but am happy if the two other folks I added are happy... Comment Actions I went ahead and landed this for now. It's easy to move the 3 new files to their own library later on if we decide it's something we want to do. Thanks for the patch! Comment Actions Unfortunately this seems to break the modular build. Would you mind taking a look? I'm going to revert the patch to get the bots going again. https://green.lab.llvm.org/green/view/LLDB/job/lldb-cmake/41306/console
Comment Actions Thanks for the revert! Is there any documentation for that LLVM_ENABLE_MODULES build config anywhere?
Comment Actions Relanded in 73e585e44d68cf77e2e3274e98c9615156a7d909, with the new files in a new WindowsDriver library. Comment Actions I'm not exactly sure why, but this change seems to be causing the Driver/cl-options.c test to fail on the PS4 Windows bot: https://lab.llvm.org/staging/#/builders/204/builds/1343 It was also failing previously after the original commit until it was reverted at which point it started to pass again. Comment Actions It fails on this: // Validate that the default triple is used when run an empty tools dir is specified // RUN: %clang_cl -vctoolsdir "" -### -- %s 2>&1 | FileCheck %s --check-prefix VCTOOLSDIR // VCTOOLSDIR: "-triple" "{{[a-zA-Z0-9_-]*}}-pc-windows-msvc19.20.0" With this: C:\buildbot-root\llvm-clang-x86_64-sie-win\llvm-project\clang\test\Driver\cl-options.c:761:16: error: VCTOOLSDIR: expected string not found in input // VCTOOLSDIR: "-triple" "{{[a-zA-Z0-9_-]*}}-pc-windows-msvc19.20.0" ^ <stdin>:1:1: note: scanning from here clang version 15.0.0 (https://github.com/llvm/llvm-project.git 0574b5fc657451c9d13d3f6d8fe14ea15c23a681) ^ <stdin>:5:68: note: possible intended match here "c:\\buildbot-root\\llvm-clang-x86_64-sie-win\\build\\bin\\clang.exe" "-cc1" "-triple" "x86_64-pc-windows-msvc19.29.30137" ... That test was added in D85998. I think this is a true regression. findVCToolChainViaCommandLine() used to return true on present-but-empty strings, but llvm::findVCToolChainViaCommandLine() uses the empty string as "not set". The fix is probably to make llvm::findVCToolChainViaCommandLine() take Optional<StringRef>s instead, and use the Optional value instead of string emptiness. It's late over here, so I won't get to that myself today. Feel free to revert for now. Comment Actions I've reverted this and the follow-up change to fix the build in 437d4e01fe4c057509dff30efd560049ad07bc99. Comment Actions Thanks for the revert! FWIW, also failed on https://ci.chromium.org/ui/p/chromium/builders/try/win_upload_clang/2069/overview / https://logs.chromium.org/logs/chromium/buildbucket/cr-buildbucket/8822456541383185105/+/u/package_clang/stdout?format=raw . So maybe it's not a super exotic failure. Comment Actions The bot that broke last time stayed green on the reland: https://lab.llvm.org/staging/#/builders/204/builds/1591 :) |
You could also use saver().save(...) below and keep this member intact. That would save some memory allocations.