64-bit windows build.

[nikomatsakis]

Currently the windows build is 32-bit only. This is mostly a matter of figuring out the right build environment and editing the Makefiles, though there may be some changes needed to the x86_64 assembly as the windows calling convention is not the same as the one used on Mac and linux.

[z0w0]

@graydon just following up as you are assigned to this issue (although I can't see when you were assigned unfortunately, and can only assume it was when this issue was made). Are you still planning on completing this? Not volunteering because I don't personally run Windows, just trying to see if there's any progress. Sounds like a pretty significant change and I can't see anything particular holding it back, so it would be nice to see someone finish this off.

[bstrie]

The current milestone here is "well-covered", but I think it would be suicide to release 1.0 without supporting the world's most popular desktop platform. It would also completely destroy the notion of ever using Rust for the sort of games that currently require C++. I know we don't currently have a milestone for 1.0, but I'm tempted to reassign this to "backwards-compatible" just to ensure that it doesn't slip.

[metajack]

renominating for production ready

[graydon]

accepted for production-ready milestone

[graydon]

accepted for production-ready milestone

[klutzy]

#8488 and #8840 enabled rustc to cross-build for mingw-w64. With cross-built rustrt.dll and std-<hash>.dll inside rustc/x86_64-w64-mingw32/bin/, your rustc can build 64-bit exe.

What's missing now:

• morestack. I think it is not so hard, but GS register holds stack range thus it should be maintained.
• stack unwinding. In 64-bit windows, there are two methods available: SJLJ and SEH. (no dwarf!) Also note that win32 SEH and win64 SEH are totally different. I guess llvm supports SJLJ but no SEH. (See also @thadguidry's comment on #7953) SEH is better, so we have to use it before 1.0 lands.

Also, I think it's better to use mingw-w64 for both win32/win64, to minimize platform difference (e.g. #8663).

[klutzy]

I found win64/SEH patchset from LDC (via ldc-developers/ldc#166 and LDC wiki). It is not merged in trunk now, and I don't know any further discussion from LDC or LLVM.

[catamorphism]

1.0, high

[vadimcn]

@klutzy, so what's the current status on win64 support?

[klutzy]

@vadimcn when I cross-built 64-bit rustc recently (maybe 2 months ago?):

• ../configure --build=x86_64-w64-mingw32 && make RUSTFLAGS="-Z no-opt" seemed to work.
• 64-bit rustc crashed if it is built with optimization flag. It means plain make crashes during stage2.
• unwinding didn't work. task failure led process exit.

(I used mingw-builds x64 + win32 threads + seh unwinding.)
Currently src/libstd/rt/unwind.rs may need __gcc_personality_seh0 patch, but I guess the status has not changed much.

[vadimcn]

Huh, after rebasing my changes on top of recent rust master, Rust build no longer crashes in stage1 when compiling with optimizations, and gets all the way to compiletest.

[vadimcn]

I have a branch here, which gets all the way to stage2 and passes almost all tests, when built with RUSTFLAGS="-Z no-opt". Unfortunately, after rebasing on top of the current rust master, it started crashing again while building stage2 libstd :(

Anyhow, I thought some of you folks might be interested. @klutzy, @thadguidry, @alexcrichton, @kvanberendonck

[alexcrichton]

That looks really impressive, nice work! I'd be willing to help you upstream any of those LLVM patches, they all look pretty easily upstream-able.

[vadimcn]

Ok, now it works on top of current rust master: https://github.com/vadimcn/rust/compare/Win64
The only outstanding issue is "what to do about noreturn functions?"

[alexcrichton]

Perhaps the noreturn attribute could be omitted when compiling for win64 for now? We could have an open issue about fixing this in upstream LLVM.

[thestinger]

LLVM will infer noreturn itself in many cases. It's an inherent property of some intrinsics like llvm.trap too.

[alexcrichton]

Oh dear, that's a good point. It sounds like we'll need to fix upstream to turn on optimizations.

@vadimcn, I'd be fine if you wanted to upstream to those patches to rust for now, and we could even set up a 64-nopt-c builder (like we have for 32-bit windows) to help prevent some regressions.

[vadimcn]

Actually, stripping 'noreturn' does help.
However, there's a similar problem with the 'resume' instruction at the end
of landing pads. And 'resume' is intrinsically 'noreturn', so there isn't
an easy fix for that...

On Apr 14, 2014, at 12:56 PM, Alex Crichton notifications@github.com
wrote:

Oh dear, that's a good point. It sounds like we'll need to fix upstream to
turn on optimizations.

@vadimcn https://github.com/vadimcn, I'd be fine if you wanted to
upstream to those patches to rust for now, and we could even set up a
64-nopt-c builder (like we have for 32-bit windows) to help prevent some
regressions.

—
Reply to this email directly or view it on
GitHubhttps://github.com//issues/1237#issuecomment-40410497
.

[vadimcn]

Okay, I made a fix in LLVM for noreturns, and it all works now: https://github.com/vadimcn/rust/compare/Win64 (rebased on top of the pending LLVM upgrade). As before, you'll need to fetch Win64 branch from llvm and compiler-rt repos in order to build this.

I am going to wait until #13513 lands, before submitting this as a PR.

[alexcrichton]

Could you submit the LLVM patches upstream beforehand? I'm more than willing to help out, and I'd love to keep using upstream LLVM!

The second one looks trivial enough (it may need some tests), but the first one looks a little more involved...

[vadimcn]

Yup, working on it...

[vadimcn]

Here's Phabricator review for it, btw: http://reviews.llvm.org/D3418. It's going very slowly.

[kud1ing]

Is this fixed by #13692 ?

[alexcrichton]

Not quite just yet, I think we can close this once we have a 64-bit windows snapshot and we're bootstrapping on 64-bit windows (with at least some tests passing).

[brson]

Nominating for removal from milestone. Our ability to do this is entirely dependent on upstream LLVM.

[pnkfelix]

Removing from milestone. Keeping at P-high.

(If LLVM grows 64-bit Windows support, then we can revisit this choice.)

[brson]

@vadimcn Landed 64-bit SEH support in LLVM: http://reviews.llvm.org/rL211399.

[vadimcn]

Thought I'd post an update on the status of win64:

• SEH unwind info emission support has been merged into LLVM master.
• Rust compiler bootstraps up to stage2, but doesn't pass tests (compiletest crashes at startup).

Known problems:

• as mentioned above, compiletest is broken. It seems that the culprit is libgreen: when I switched compiletest to use libnative, it got through many tests, though in the end it hung - after complaining about task 'receiving on a closed channel'.
• debug info is broken - nevermind: line numbers are also broken in the latest nightly

I've published the current state of my repo in on github: https://github.com/vadimcn/rust/commits/Win64. To build it you'll need to fetch LLVM master and run configure --build=x86_64-w64-mingw32.

[vadimcn]

Now somebody's gonna have to set up a build bot for it . 😉