Remove segmented stack prelude on Windows

[klutzy]

On Windows, stack overflow is detected via two ways:

1. Threads have guard page at the end of stack, so it will cause segmentation fault if you try to access guard page.
   (To be precise, guard page is set at uncommitted page therefore it detects when to commit page or fail if stack is full).
   Green threads also have guard page via VirtualProtect.
2. Guard page is insufficient if a function consumes stack more than page size, thus "jumps" over guard page. To prevent this, Windows compilers add __chkstk() or _alloca() if frame size is greater than 4096. The checker functions tries to access all pages between base pointer and stack pointer.

LLVM also has such support. This is already happening:

$ cat a.rs
#![no_std]
#![crate_type = "lib"]
pub fn large() {
    let a = [0u8, ..4096];
}

$ rustc a.rs --target=i686-pc-mingw32 --emit=asm -o a.win.s

__ZN5large20h4dd5255028807332baa4v0.0E::
    .cfi_startproc
    leal    -4104(%esp), %ecx
    cmpl    %fs:20, %ecx
    ja  LBB0_0
    pushl   $0
    pushl   $4104
    calll   ___morestack
    retl
LBB0_0:
    movl    $4104, %eax
    calll   __alloca
...

So we can completely remove __morestack here and use _alloca for detection.

Also, currently LLVM uses %fs:0x14 for segmetend stack support, but it seems to break a lot of things: See #13259 and its related issues.

cc #11871

[klutzy]

proof-of-concept here. This passes check-stage1-{rpass, rfail, cfail, rmake} and seems to work well?
For end-users, the only change is that the program doesn't print task '<main>' has overflowed its stack message but just dies, and it leaves SIGSEGV instead of SIGILL.

[alexcrichton]

Note that we are very intentionally still using segmented stacks because we would like the ability to run library code when a task overflows the stack. This is precisely to print that the stack has overflowed, as well as leaving the door open in the future to do something more flavorful.

We would need to figure out how to catch SIGSEGV and print a message or explicitly decide to not have this feature before moving forward with this issue.

[alexcrichton]

I do agree, however, that I think the segmented stack prelude may be causing more trouble than it's worth now. I suspect, but have never confirmed, that this is not helping FreeBSD by having segmented stacks enabled.

[retep998]

By using SEH exceptions handling we'd be able to catch this exact exception and call library code instead of merely causing a SIGSEGV.

[thestinger]

@retep998: LLVM can't really support recovering from a stack overflow. The best it can do is allow you to block the thread forever, because it would be undefined behaviour to unwind from a location it didn't consider as possibly unwinding. It's also impossible to write low-level Rust code that's correct in the presence of unwinding from any function prelude.

[retep998]

@thestinger We don't have to unwind. We just have to catch the problem, inform the user that there was a stack overflow somehow (like we do now with a message to stderr), and then kill the program. Using SEH would just make it easy to catch stack overflows on windows without the prelude and without figuring out whether a SIGSEGV was caused by a stackoverflow.