Make rust_stack_exhausted a lang item

[brson]

cc #9839. Right now if you don't link to the standard library you get a link error because __morestack expects a symbol called rust_stack_exhausted to exist.

Add a "stack_exhausted" lang item. For every compilation unit, if the lang item doesn't exist, emit the code

extern "rust-intrinsic" { fn abort() -> !; }

#[no_mangle] pub extern "C" fn __rust_stack_exhausted() {
    unsafe { abort() }
}

If it does exist, emit the same function, but call the lang item.

This would work in our current scheme where std defines what happens when the stack runs out, but not if we refactored std like #11828, so that the lowest levels of the crate hierarchy don't know the failure policy.

[thestinger]

The morestack-based stack overflow checking doesn't work at all in a kernel. I think this would just hide the issue. Rust can also only generate position-independent code and is unable to easily define memcpy, memset and memmove which will be called by LLVM so it's only one of many blockers.

I've been tagging these as A-freestanding so you can look under that to find the other issues.

[brson]

Why doesn't morestack work in a kernel?

[alexcrichton]

The morestack-based stack overflow checking doesn't work at all in a kernel

That is not true. I have written a kernel that makes use of morestack checks. It is just a little more difficult to set up the state of the world such that the stack checking works.

[thestinger]

@alexcrichton: That's exactly what I mean though. It's broken out-of-the-box and will be a silent hazard in a freestanding project like a Linux kernel module.

[brson]

The problem is that, without doing some setup, the morestack checks will trip incorrectly?

[brson]

Is it true that this incorrect trip only happens in kernel space? Does userpace always initialize our morestack TCB slot to zero for us? (ISTR it doesn't in some cases)

[thestinger]

@brson: That issue along with the possibility of setting it up not being an option if you're integrating with an existing kernel like Linux. I don't know if it's ever a problem in userland, as I haven't seen it go wrong yet.

[brson]

We could probably provide portable routines for initializing morestack. If this is only a problem for kernelspace it doesn't seem too burdensome to ask them to call an init function. Of course, having an option to disable morestack generation would also be useful.

As long as we are using morestack, I'd like to make it as convenient as we can.

[huonw]

Could we just have this have normal lang-item detection?

If there is any function that will require the split-stack header, emit a "requires stack_exhausted" error, which at least means we don't get linking errors.

[thestinger]

As long as it's still possible to build with without marking every function as #[no_split_stack] :P. It is now by going through either llc or clang and relying on a guard page for safety. Of course, it's not a full solution until LLVM has a chkstk equivalent on more than Windows, and morestack will still be required without a MMU.

[alexcrichton]

Closing, this was done in #14293