Add support for 64-bit Windows builds #16261
Conversation
_WIN32 is defined for 64-bit builds as well, so test for _WIN64 first.
This is important when building with --disable-jemalloc: unlike jemalloc, msvcrt does not align on 16 bytes unless asked to.
… has a legitimate need to set them.
The original trick used to trigger unwinds would not work with GCC's implementation of SEH, so I had to invent a new one: rust_try now consists of two routines: the outer one, whose handler triggers unwinds, and the inner one, that stops unwinds by having a landing pad that swallows exceptions and passes them on to the outer routine via a normal return.
src/librustrt/unwind.rs
Outdated
There was a problem hiding this comment.
Don't think so. It's a typo. :(
|
\o/ yay!! |
src/librustrt/stack.rs
Outdated
There was a problem hiding this comment.
This is to allow setting morestack stack limit from libnative without touching Windows's stack bounds TIB fields (gs:0x08 and gs:0x10). Since libnative relies on os-managed stacks, it should not mess with these. Currently it doesn't even do it correctly, because gs:0x10 is supposed to be the commit limit, not the reserve limit, as @klutzy had explained here.
There was a problem hiding this comment.
If that's the case, this function needs to have some comments to justify its existence and explain what it's doing. Also, if the other function is wrong, why not just delete it? Surely it must be doing something?
There was a problem hiding this comment.
The original function is still needed for libgreen, because it creates stacks from scratch.
I know, having two of them is not optimal, but couldn't think of anything better. I am open to suggestions...
There was a problem hiding this comment.
Thinking about this, could you just update libnative to call record_stack_limit as opposed to record_stack_bounds. You can move the RED_ZONE addition into record_stack_limit as well
There was a problem hiding this comment.
You mean record_sp_limit? There's a number of uses which add a value other than RED_ZONE:
https://github.com/rust-lang/rust/blob/master/src/librustrt/stack.rs#L71
https://github.com/rust-lang/rust/blob/master/src/libstd/rand/os.rs#L213
https://github.com/rust-lang/rust/blob/master/src/libstd/rand/os.rs#L217
I think it's better left alone.
Maybe call libnative variant record_os_managed_stack_bounds?
There was a problem hiding this comment.
Ok, that sounds good to me. I think that the green/native naming is a bit of a misnomer, but record_os_managed_stack_bounds seems good.
There was a problem hiding this comment.
Can you also add a comment to the function explaining how its different from the others?
|
🌴 this is exciting! |
There was a problem hiding this comment.
What is changed by the line? (was this causing problem on some environments?)
There was a problem hiding this comment.
Purely cosmetic. Since we are now on mingw64, I thought we should use its' triple for consistency.
There was a problem hiding this comment.
I think I'll just have to trust you on this one!
For a good measure, implemented target_record_stack_bounds for 32-bit Windows as well.
|
r? |
internal: Move query limits to the caller Prior we calculated up to `limit` entries from a query, then filtered from that leaving us with less entries than the limit in some cases (which might give odd completion behavior due to items disappearing). This changes it so we filter before checking the limit.
4 participants
Finally landed all the required fixes in LLVM master!
These 4 tests currently fail in win64 build, I suspect there's some ABI conformance bug:
run-pass/extern-pass-TwoU64s.rs
run-pass/extern-pass-empty.rs
run-pass/extern-return-TwoU64s.rs
run-pass/tcp-connect-timeouts.rs
Closes #1237