Implement unwinding for i686 MSVC #30448

alexcrichton · 2015-12-17T22:13:49Z

These commits perform a few high-level changes with the goal of enabling i686 MSVC unwinding:

LLVM is upgraded to pick up the new exception handling instructions and intrinsics for MSVC. This puts us somewhere along the 3.8 branch, but we should still be compatible with LLVM 3.7 for non-MSVC targets.
All unwinding for MSVC targets (both 32 and 64-bit) are implemented in terms of this new LLVM support. I would like to also extend this to Windows GNU targets to drop the runtime dependencies we have on MinGW, but I'd like to land this first.
Some tests were fixed up for i686 MSVC here and there where necessary. The full test suite should be passing now for that target.

In terms of landing this I plan to have this go through first, then verify that i686 MSVC works, then I'll enable make check on the bots for that target instead of just make as-is today.

Closes #25869

rust-highfive · 2015-12-17T22:14:01Z

r? @nikomatsakis

(rust_highfive has picked a reviewer for you, use r? to override)

alexcrichton · 2015-12-17T22:14:49Z

cc @rust-lang/compiler, there's some pretty significant trans changes here!
cc @vadimcn, lots of windows changes
cc @brson, build system changes! (and llvm changes)

alexcrichton · 2015-12-18T01:36:23Z

Oh and I think it's important to wait for travis before r+'ing this b/c that make sure that we're still compatible with LLVM 3.7 (which I believe is important for now)

sanxiyn · 2015-12-18T04:44:58Z

Travis failed compiling RustWrapper.cpp on LLVM_VERSION_MINOR < 8 paths.

bors · 2015-12-18T17:12:26Z

☔ The latest upstream changes (presumably #30457) made this pull request unmergeable. Please resolve the merge conflicts.

nikomatsakis · 2015-12-19T02:17:52Z

src/libcore/intrinsics.rs

@@ -686,5 +686,8 @@ extern "rust-intrinsic" {
    /// Rust's "try catch" construct which invokes the function pointer `f` with
    /// the data pointer `data`, returning the exception payload if an exception
    /// is thrown (aka the thread panics).
+    #[cfg(not(stage0))]
+    pub fn try(f: fn(*mut u8), data: *mut u8, local_ptr: *mut u8) -> i32;


maybe update the comment with what the heck local_ptr is?

vadimcn · 2015-12-19T22:08:06Z

Nice work, @alexcrichton!

After the first pass this looks fine to me.
I'll try to find some time to build this branch and play with it. I might have more insights then.

bors · 2015-12-21T23:37:02Z

☔ The latest upstream changes (presumably #30352) made this pull request unmergeable. Please resolve the merge conflicts.

brson · 2015-12-22T01:04:49Z

Impressive.

alexcrichton · 2015-12-22T23:27:19Z

@nikomatsakis brought up some interesting points on IRC that I didn't realize here. It turns out that today we actually cache cleanups for landing pads, for example with code like:

pub fn foo() {
    let _a = Foo;
    bar();
    let _b = Foo;
    bar();
}

There are two landing pads for this function from the two calls to bar, and both landing pads need a cleanup of the local variable _a. Today we only translate the cleanup of _a once, however, and the landing pad of _b will branch to the cleanup of _a. This is visible in the generated IR.

A problem here, however, is that with cleanuppad this is not possible. The same basic block (e.g. the drop of _a) is being shared between two cleanuppad instances, so it doesn't clearly belong to either one to add a funclet bundle to it. This branch currently works accidentally by basically breaking the cache. For example the IR of this PR re-translates the drop of _a twice.

I just remembered, however, that the cleanupret instruction can take a label to continue unwinding to. I believe we can use this to chain together cleanup pads in a way similar to how landingpad/GNU works.

This'll take some work to get working, but seems critical enough to get it done before landing.

alexcrichton · 2015-12-23T00:15:57Z

Ok, I've now pushed an updated version which handles caching better on MSVC. The caching for GNU/landingpad exceptions should be the same as it was before, and the IR for the snippet above in MSVC shows the caching being used as well.

Currently the caching isn't as aggressively used on MSVC as it is on GNU b/c on MSVC you can't jump to the middle of a set of cleanup scopes, only the front. Perhaps that only matters for corner cases though?

alexcrichton · 2016-01-29T21:18:09Z

@bors: r=nikomatsakis 11698cb

bors · 2016-01-29T23:37:47Z

⌛ Testing commit 11698cb with merge 1813eca...

bors · 2016-01-29T23:53:27Z

💔 Test failed - auto-mac-64-opt

alexcrichton · 2016-01-29T23:56:18Z

@bors: r=nikomatsakis f9b267a force

(gonna see if we can get the bots to not build LLVM a million times)

bors · 2016-01-29T23:56:23Z

⌛ Testing commit f9b267a with merge d853d8a...

bors · 2016-01-30T00:16:25Z

💔 Test failed - auto-win-msvc-32-opt

This brings some routine upgrades to the bundled LLVM that we're using, the most notable of which is a bug fix to the way we handle range asserts when loading the discriminant of an enum. This fix ended up being very similar to f9d4149 where we basically can't have a range assert when loading a discriminant due to filling drop, and appropriate flags were added to communicate this to `trans::adt`.

This commit transitions the compiler to using the new exception handling instructions in LLVM for implementing unwinding for MSVC. This affects both 32 and 64-bit MSVC as they're both now using SEH-based strategies. In terms of standard library support, lots more details about how SEH unwinding is implemented can be found in the commits. In terms of trans, this change necessitated a few modifications: * Branches were added to detect when the old landingpad instruction is used or the new cleanuppad instruction is used to `trans::cleanup`. * The return value from `cleanuppad` is not stored in an `alloca` (because it cannot be). * Each block in trans now has an `Option<LandingPad>` instead of `is_lpad: bool` for indicating whether it's in a landing pad or not. The new exception handling intrinsics require that on MSVC each `call` inside of a landing pad is annotated with which landing pad that it's in. This change to the basic block means that whenever a `call` or `invoke` instruction is generated we know whether to annotate it as part of a cleanuppad or not. * Lots of modifications were made to the instruction builders to construct the new instructions as well as pass the tagging information for the call/invoke instructions. * The translation of the `try` intrinsics for MSVC has been overhauled to use the new `catchpad` instruction. The filter function is now also a rustc-generated function instead of a purely libstd-defined function. The libstd definition still exists, it just has a stable ABI across architectures and leaves some of the really weird implementation details to the compiler (e.g. the `localescape` and `localrecover` intrinsics).

alexcrichton · 2016-01-30T00:25:41Z

@bors: r=nikomatsakis 58f1b9c force

These commits perform a few high-level changes with the goal of enabling i686 MSVC unwinding: * LLVM is upgraded to pick up the new exception handling instructions and intrinsics for MSVC. This puts us somewhere along the 3.8 branch, but we should still be compatible with LLVM 3.7 for non-MSVC targets. * All unwinding for MSVC targets (both 32 and 64-bit) are implemented in terms of this new LLVM support. I would like to also extend this to Windows GNU targets to drop the runtime dependencies we have on MinGW, but I'd like to land this first. * Some tests were fixed up for i686 MSVC here and there where necessary. The full test suite should be passing now for that target. In terms of landing this I plan to have this go through first, then verify that i686 MSVC works, then I'll enable `make check` on the bots for that target instead of just `make` as-is today. Closes #25869

bors · 2016-01-30T00:25:45Z

⌛ Testing commit 58f1b9c with merge 303892e...

bors · 2016-01-30T03:17:23Z

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-debug-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-x-android-t, auto-linux-cross-opt, auto-linux-musl-64-opt, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-mac-ios-opt, auto-win-gnu-32-nopt-t, auto-win-gnu-32-opt, auto-win-gnu-64-nopt-t, auto-win-gnu-64-opt, auto-win-msvc-32-opt, auto-win-msvc-64-opt

alexcrichton · 2016-01-30T03:28:57Z

🌙

rustc LLVM was upgraded in: rust-lang/rust#30448 This fixes compatibility with API changes Fixes #38

rust-highfive assigned nikomatsakis Dec 17, 2015

alexcrichton mentioned this pull request Dec 17, 2015

test: Get some tests working on MSVC 32-bit #30168

Closed

alexcrichton force-pushed the llvmup branch 4 times, most recently from 3a1a73a to ce42d53 Compare December 18, 2015 01:35

alexcrichton force-pushed the llvmup branch 3 times, most recently from 8e31506 to ec26a6c Compare December 18, 2015 18:34

alexcrichton mentioned this pull request Dec 18, 2015

Initial emscripten work #30453

Closed

alexcrichton force-pushed the llvmup branch from ec26a6c to 122f9cb Compare December 18, 2015 21:55

nikomatsakis reviewed Dec 19, 2015
View reviewed changes

alexcrichton force-pushed the llvmup branch 2 times, most recently from 63dede1 to ba96aa3 Compare December 21, 2015 22:54

alexcrichton force-pushed the llvmup branch 4 times, most recently from 0fcca2c to 2b49991 Compare December 22, 2015 00:47

alexcrichton force-pushed the llvmup branch from 03ef35c to f492521 Compare December 22, 2015 23:16

alexcrichton force-pushed the llvmup branch from f492521 to bd33af9 Compare December 23, 2015 00:12

alexcrichton force-pushed the llvmup branch from 11698cb to f9b267a Compare January 29, 2016 23:55

alexcrichton added 3 commits January 29, 2016 16:25

Get tests working on MSVC 32-bit

58f1b9c

alexcrichton force-pushed the llvmup branch from f9b267a to 58f1b9c Compare January 30, 2016 00:25

bors merged commit 58f1b9c into rust-lang:master Jan 30, 2016

This was referenced Jan 30, 2016

[MIR] Refactor the MIR translator to use LLVM Builder directly #31282

Merged

Issue #5977 - Generalizing RawNullablePointer to RawForbiddenValue #31215

Closed

alexcrichton deleted the llvmup branch January 30, 2016 03:28

frewsxcv added a commit to rust-fuzz/afl.rs that referenced this pull request Jan 31, 2016

Fix build compilation with latest LLVM version

5b727dd

rustc LLVM was upgraded in: rust-lang/rust#30448 This fixes compatibility with API changes Fixes #38

frewsxcv mentioned this pull request Jan 31, 2016

Fix build compilation with latest LLVM version rust-fuzz/afl.rs#40

Merged

alexcrichton mentioned this pull request Feb 3, 2016

Compilation is 350x times slower in release for r68k #31381

Closed

semarie mentioned this pull request Feb 3, 2016

rustc build core dump on OpenBSD #31363

Closed

alexcrichton mentioned this pull request Feb 5, 2016

Regression in compile times after LLVM was upgraded #31435

Closed

tkelman mentioned this pull request Mar 9, 2016

Add patches for LLVM 3.8.0 JuliaLang/julia#15417

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Implement unwinding for i686 MSVC #30448

Implement unwinding for i686 MSVC #30448

alexcrichton commented Dec 17, 2015

rust-highfive commented Dec 17, 2015

alexcrichton commented Dec 17, 2015

alexcrichton commented Dec 18, 2015

sanxiyn commented Dec 18, 2015

bors commented Dec 18, 2015

nikomatsakis Dec 19, 2015

alexcrichton Dec 20, 2015

vadimcn commented Dec 19, 2015

bors commented Dec 21, 2015

brson commented Dec 22, 2015

alexcrichton commented Dec 22, 2015

alexcrichton commented Dec 23, 2015

alexcrichton commented Jan 29, 2016

bors commented Jan 29, 2016

bors commented Jan 29, 2016

alexcrichton commented Jan 29, 2016

bors commented Jan 29, 2016

bors commented Jan 30, 2016

alexcrichton commented Jan 30, 2016

bors commented Jan 30, 2016

bors commented Jan 30, 2016

alexcrichton commented Jan 30, 2016

Implement unwinding for i686 MSVC #30448

Implement unwinding for i686 MSVC #30448

Conversation

alexcrichton commented Dec 17, 2015

rust-highfive commented Dec 17, 2015

alexcrichton commented Dec 17, 2015

alexcrichton commented Dec 18, 2015

sanxiyn commented Dec 18, 2015

bors commented Dec 18, 2015

nikomatsakis Dec 19, 2015

Choose a reason for hiding this comment

alexcrichton Dec 20, 2015

Choose a reason for hiding this comment

vadimcn commented Dec 19, 2015

bors commented Dec 21, 2015

brson commented Dec 22, 2015

alexcrichton commented Dec 22, 2015

alexcrichton commented Dec 23, 2015

alexcrichton commented Jan 29, 2016

bors commented Jan 29, 2016

bors commented Jan 29, 2016

alexcrichton commented Jan 29, 2016

bors commented Jan 29, 2016

bors commented Jan 30, 2016

alexcrichton commented Jan 30, 2016

bors commented Jan 30, 2016

bors commented Jan 30, 2016

alexcrichton commented Jan 30, 2016