-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Mingw-w64 support #8488
Mingw-w64 support #8488
Conversation
What was the error message(s)/type of crash if there wasn't a custom |
If we need LLVM patches for stack unwinding, I could throw those in with #8328. I don't think I'm going to find the rusti fixes soon, but we don't want to change LLVM too often. |
Wow, this is great! Thanks so much. |
@huonw segfault from non-main thread. #[start]
fn start(argc: int, argv: **u8, crate_map: *u8) -> int {
do std::rt::start_on_main_thread(argc, argv, crate_map) {
println("start_on_main_thread");
do spawn {
println("spawn");
}
};
return 0;
} But if I change |
With one more llvm patch (needed to build llvm on mingw-w64/SEH),
However,
I don't know yet what it means. |
@@ -247,4 +248,15 @@ mod dl { | |||
fn GetProcAddress(handle: *libc::c_void, name: *libc::c_char) -> *libc::c_void; | |||
fn FreeLibrary(handle: *libc::c_void); | |||
} | |||
|
|||
#[cfg(target_arch = "x86_64")] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm probably missing something, but this code looks like it's exactly the same as the x86
code; is it required to be duplicated like this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
extern "stdcall" { ... }
vs extern { ... }
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, omitting "stdcall" (see also #8509), although for subtle reason.
If extern "stdcall"
is given, rustc produces llvm's function declaration with callconv=X86StdcallCallConv, even if win64 does not have such convention.
Then llvm makes it worse: it mangles function name e.g. "MessageBoxA" -> "_MessageBox@16" but win64 only has "MessageBoxA", so link fails.
I think llvm is wrong (it should ignore wrong callconv), but don't know rustc is wrong or not.
This needs a rebase (also, #8328 has now landed, if this was blocked on it). |
Win64 convention does not use underscore.
Uses ArbitraryUserPointer area at gs:0x28.
Some extern blobs are duplicated without "stdcall" abi, since Win64 does not use any calling convention. (Giving any abi to them causes llvm producing wrong bytecode.)
This patch saves and restores win64's nonvolatile registers. This patch also saves stack information of thread environment block (TEB), which is at %gs:0x08 and %gs:0x10.
rebased; fixed the segfault issue mentioned above ( |
This patchset enables rustc to cross-build mingw-w64 outputs. Tested on mingw + mingw-w64 (mingw-builds, win64/seh/win32-threads/gcc-4.8.1). I also patched llvm to support Win64 stack unwinding. klutzy/llvm@ebe22bd I cross-built test/run-pass/smallest-hello-world.rs and confirmed it works. However, I also found something went wrong if I don't have custom `#[start]` routine.
Forgot to say llvm patches mentioned above: rebased on current |
Those patches still need to be merged, right? It doesn't look like they were included in this. |
yes, llvm patches are not merged to current llvm therefore still needed. |
Move testing of cargo dev new_lint to cargo dev workflow This should be placed there. No need to run this in PR CI, if clippy_dev isn't touched. (It will be run by bors anyway) changelog: none
This patchset enables rustc to cross-build mingw-w64 outputs.
Tested on mingw + mingw-w64 (mingw-builds, win64/seh/win32-threads/gcc-4.8.1).
I also patched llvm to support Win64 stack unwinding.
klutzy/llvm@ebe22bd
I cross-built test/run-pass/smallest-hello-world.rs and confirmed it works.
However, I also found something went wrong if I don't have custom
#[start]
routine.