-
Notifications
You must be signed in to change notification settings - Fork 12.5k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Auto merge of #26741 - alexcrichton:noinline-destructors, r=brson
This PR was originally going to be a "let's start running tests on MSVC" PR, but it didn't quite get to that point. It instead gets us ~80% of the way there! The steps taken in this PR are: * Landing pads are turned on by default for 64-bit MSVC. The LLVM support is "good enough" with the caveat the destructor glue is now marked noinline. This was recommended [on the associated bug](https://llvm.org/bugs/show_bug.cgi?id=23884) as a stopgap until LLVM has a better representation for exception handling in MSVC. The consequence of this is that MSVC will have a bit of a perf hit, but there are possible routes we can take if this workaround sticks around for too long. * The linker (`link.exe`) is now looked up in the Windows Registry if it's not otherwise available in the environment. This improves using the compiler outside of a VS shell (e.g. in a MSYS shell or in a vanilla cmd.exe shell). This also makes cross compiles via Cargo "just work" when crossing between 32 and 64 bit! * TLS destructors were fixed to start running on MSVC (they previously weren't running at all) * A few assorted `run-pass` tests were fixed. * The dependency on the `rust_builtin` library was removed entirely for MSVC to try to prevent any `cl.exe` compiled objects get into the standard library. This should help us later remove any dependence on the CRT by the standard library. * I re-added `rust_try_msvc_32.ll` for 32-bit MSVC and ensured that landing pads were turned off by default there as well. Despite landing pads being enabled, there are still *many* failing tests on MSVC. The two major classes I've identified so far are: * Spurious aborts. It appears that when optimizations are enabled that landing pads aren't always lined up properly, and sometimes an exception being thrown can't find the catch block down the stack, causing the program to abort. I've been working to reduce this test case but haven't been met with great success just yet. * Parallel codegen does not work on MSVC. Our current strategy is to take the N object files emitted by the N codegen threads and use `ld -r` to assemble them into *one* object file. The MSVC linker, however, does not have this ability, and this will need to be rearchitected to work on MSVC. I will fix parallel codegen in a future PR, and I'll also be watching LLVM closely to see if the aborts... disappear!
- Loading branch information
Showing
18 changed files
with
554 additions
and
80 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,239 @@ | ||
| // Copyright 2015 The Rust Project Developers. See the COPYRIGHT | ||
| // file at the top-level directory of this distribution and at | ||
| // http://rust-lang.org/COPYRIGHT. | ||
| // | ||
| // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or | ||
| // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license | ||
| // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your | ||
| // option. This file may not be copied, modified, or distributed | ||
| // except according to those terms. | ||
|
|
||
| //! MSVC-specific logic for linkers and such. | ||
| //! | ||
| //! This module contains a cross-platform interface but has a blank unix | ||
| //! implementation. The Windows implementation builds on top of Windows native | ||
| //! libraries (reading registry keys), so it otherwise wouldn't link on unix. | ||
| //! | ||
| //! Note that we don't have much special logic for finding the system linker on | ||
| //! any other platforms, so it may seem a little odd to single out MSVC to have | ||
| //! a good deal of code just to find the linker. Unlike Unix systems, however, | ||
| //! the MSVC linker is not in the system PATH by default. It also additionally | ||
| //! needs a few environment variables or command line flags to be able to link | ||
| //! against system libraries. | ||
| //! | ||
| //! In order to have a nice smooth experience on Windows, the logic in this file | ||
| //! is here to find the MSVC linker and set it up in the default configuration | ||
| //! one would need to set up anyway. This means that the Rust compiler can be | ||
| //! run not only in the developer shells of MSVC but also the standard cmd.exe | ||
| //! shell or MSYS shells. | ||
| //! | ||
| //! As a high-level note, all logic in this module for looking up various | ||
| //! paths/files is copied over from Clang in its MSVCToolChain.cpp file, but | ||
| //! comments can also be found below leading through the various code paths. | ||
|
|
||
| use std::process::Command; | ||
| use session::Session; | ||
|
|
||
| #[cfg(windows)] | ||
| mod registry; | ||
|
|
||
| #[cfg(windows)] | ||
| pub fn link_exe_cmd(sess: &Session) -> Command { | ||
| use std::env; | ||
| use std::ffi::OsString; | ||
| use std::fs; | ||
| use std::path::PathBuf; | ||
| use self::registry::{RegistryKey, LOCAL_MACHINE}; | ||
|
|
||
| // When finding the link.exe binary the 32-bit version is at the top level | ||
| // but the versions to cross to other architectures are stored in | ||
| // sub-folders. Unknown architectures also just bail out early to return the | ||
| // standard `link.exe` command. | ||
| let extra = match &sess.target.target.arch[..] { | ||
| "x86" => "", | ||
| "x86_64" => "amd64", | ||
| "arm" => "arm", | ||
| _ => return Command::new("link.exe"), | ||
| }; | ||
|
|
||
| let vs_install_dir = get_vs_install_dir(); | ||
|
|
||
| // First up, we need to find the `link.exe` binary itself, and there's a few | ||
| // locations that we can look. First up is the standard VCINSTALLDIR | ||
| // environment variable which is normally set by the vcvarsall.bat file. If | ||
| // an environment is set up manually by whomever's driving the compiler then | ||
| // we shouldn't muck with that decision and should instead respect that. | ||
| // | ||
| // Next up is looking in PATH itself. Here we look for `cl.exe` and then | ||
| // assume that `link.exe` is next to it if we find it. Note that we look for | ||
| // `cl.exe` because MinGW ships /usr/bin/link.exe which is normally found in | ||
| // PATH but we're not interested in finding that. | ||
| // | ||
| // Finally we read the Windows registry to discover the VS install root. | ||
| // From here we probe for `link.exe` just to make sure that it exists. | ||
| let mut cmd = env::var_os("VCINSTALLDIR").and_then(|dir| { | ||
| let mut p = PathBuf::from(dir); | ||
| p.push("bin"); | ||
| p.push(extra); | ||
| p.push("link.exe"); | ||
| if fs::metadata(&p).is_ok() {Some(p)} else {None} | ||
| }).or_else(|| { | ||
| env::var_os("PATH").and_then(|path| { | ||
| env::split_paths(&path).find(|path| { | ||
| fs::metadata(&path.join("cl.exe")).is_ok() | ||
| }).map(|p| { | ||
| p.join("link.exe") | ||
| }) | ||
| }) | ||
| }).or_else(|| { | ||
| vs_install_dir.as_ref().and_then(|p| { | ||
| let mut p = p.join("VC/bin"); | ||
| p.push(extra); | ||
| p.push("link.exe"); | ||
| if fs::metadata(&p).is_ok() {Some(p)} else {None} | ||
| }) | ||
| }).map(|linker| { | ||
| Command::new(linker) | ||
| }).unwrap_or_else(|| { | ||
| Command::new("link.exe") | ||
| }); | ||
|
|
||
| // The MSVC linker uses the LIB environment variable as the default lookup | ||
| // path for libraries. This environment variable is normally set up by the | ||
| // VS shells, so we only want to start adding our own pieces if it's not | ||
| // set. | ||
| // | ||
| // If we're adding our own pieces, then we need to add two primary | ||
| // directories to the default search path for the linker. The first is in | ||
| // the VS install direcotry and the next is the Windows SDK directory. | ||
| if env::var_os("LIB").is_none() { | ||
| if let Some(mut vs_install_dir) = vs_install_dir { | ||
| vs_install_dir.push("VC/lib"); | ||
| vs_install_dir.push(extra); | ||
| let mut arg = OsString::from("/LIBPATH:"); | ||
| arg.push(&vs_install_dir); | ||
| cmd.arg(arg); | ||
| } | ||
| if let Some(path) = get_windows_sdk_lib_path(sess) { | ||
| let mut arg = OsString::from("/LIBPATH:"); | ||
| arg.push(&path); | ||
| cmd.arg(arg); | ||
| } | ||
| } | ||
|
|
||
| return cmd; | ||
|
|
||
| // When looking for the Visual Studio installation directory we look in a | ||
| // number of locations in varying degrees of precedence: | ||
| // | ||
| // 1. The Visual Studio registry keys | ||
| // 2. The Visual Studio Express registry keys | ||
| // 3. A number of somewhat standard environment variables | ||
| // | ||
| // If we find a hit from any of these keys then we strip off the IDE/Tools | ||
| // folders which are typically found at the end. | ||
| // | ||
| // As a final note, when we take a look at the registry keys they're | ||
| // typically found underneath the version of what's installed, but we don't | ||
| // quite know what's installed. As a result we probe all sub-keys of the two | ||
| // keys we're looking at to find out the maximum version of what's installed | ||
| // and we use that root directory. | ||
| fn get_vs_install_dir() -> Option<PathBuf> { | ||
| LOCAL_MACHINE.open(r"SOFTWARE\Microsoft\VisualStudio".as_ref()).or_else(|_| { | ||
| LOCAL_MACHINE.open(r"SOFTWARE\Microsoft\VCExpress".as_ref()) | ||
| }).ok().and_then(|key| { | ||
| max_version(&key).and_then(|(_vers, key)| { | ||
| key.query_str("InstallDir").ok() | ||
| }) | ||
| }).or_else(|| { | ||
| env::var_os("VS120COMNTOOLS") | ||
| }).or_else(|| { | ||
| env::var_os("VS100COMNTOOLS") | ||
| }).or_else(|| { | ||
| env::var_os("VS90COMNTOOLS") | ||
| }).or_else(|| { | ||
| env::var_os("VS80COMNTOOLS") | ||
| }).map(PathBuf::from).and_then(|mut dir| { | ||
| if dir.ends_with("Common7/IDE") || dir.ends_with("Common7/Tools") { | ||
| dir.pop(); | ||
| dir.pop(); | ||
| Some(dir) | ||
| } else { | ||
| None | ||
| } | ||
| }) | ||
| } | ||
|
|
||
| // Given a registry key, look at all the sub keys and find the one which has | ||
| // the maximal numeric value. | ||
| // | ||
| // Returns the name of the maximal key as well as the opened maximal key. | ||
| fn max_version(key: &RegistryKey) -> Option<(OsString, RegistryKey)> { | ||
| let mut max_vers = 0; | ||
| let mut max_key = None; | ||
| for subkey in key.iter().filter_map(|k| k.ok()) { | ||
| let val = subkey.to_str().and_then(|s| { | ||
| s.trim_left_matches("v").replace(".", "").parse().ok() | ||
| }); | ||
| let val = match val { | ||
| Some(s) => s, | ||
| None => continue, | ||
| }; | ||
| if val > max_vers { | ||
| if let Ok(k) = key.open(&subkey) { | ||
| max_vers = val; | ||
| max_key = Some((subkey, k)); | ||
| } | ||
| } | ||
| } | ||
| return max_key | ||
| } | ||
|
|
||
| fn get_windows_sdk_lib_path(sess: &Session) -> Option<PathBuf> { | ||
| let key = r"SOFTWARE\Microsoft\Microsoft SDKs\Windows"; | ||
| let key = LOCAL_MACHINE.open(key.as_ref()); | ||
| let (n, k) = match key.ok().as_ref().and_then(max_version) { | ||
| Some(p) => p, | ||
| None => return None, | ||
| }; | ||
| let mut parts = n.to_str().unwrap().trim_left_matches("v").splitn(2, "."); | ||
| let major = parts.next().unwrap().parse::<usize>().unwrap(); | ||
| let _minor = parts.next().unwrap().parse::<usize>().unwrap(); | ||
| let path = match k.query_str("InstallationFolder") { | ||
| Ok(p) => PathBuf::from(p).join("Lib"), | ||
| Err(..) => return None, | ||
| }; | ||
| if major <= 7 { | ||
| // In Windows SDK 7.x, x86 libraries are directly in the Lib folder, | ||
| // x64 libraries are inside, and it's not necessary to link agains | ||
| // the SDK 7.x when targeting ARM or other architectures. | ||
| let x86 = match &sess.target.target.arch[..] { | ||
| "x86" => true, | ||
| "x86_64" => false, | ||
| _ => return None, | ||
| }; | ||
| Some(if x86 {path} else {path.join("x64")}) | ||
| } else { | ||
| // Windows SDK 8.x installes libraries in a folder whose names | ||
| // depend on the version of the OS you're targeting. By default | ||
| // choose the newest, which usually corresponds to the version of | ||
| // the OS you've installed the SDK on. | ||
| let extra = match &sess.target.target.arch[..] { | ||
| "x86" => "x86", | ||
| "x86_64" => "x64", | ||
| "arm" => "arm", | ||
| _ => return None, | ||
| }; | ||
| ["winv6.3", "win8", "win7"].iter().map(|p| path.join(p)).find(|part| { | ||
| fs::metadata(part).is_ok() | ||
| }).map(|path| { | ||
| path.join("um").join(extra) | ||
| }) | ||
| } | ||
| } | ||
| } | ||
|
|
||
| #[cfg(not(windows))] | ||
| pub fn link_exe_cmd(_sess: &Session) -> Command { | ||
| Command::new("link.exe") | ||
| } |
Oops, something went wrong.