#[no_std] no longer works

[alexcrichton]

Once #9834 gets merged, #[no_std] will no longer work for any crates. The reason for this is that __morestack now requires a rust_stack_exhausted function. We should provide crates linking with #[no_std] a dummy implementation of __morestack which invokes abort() so that they may continue to compile.

Furthermore, a crate should also be able to say "I'm providing my own morestack" and we don't link to libmorestack.a by default regardless.

[huonw]

Could rust_stack_exhausted be a lang-item that is used (or, at least, checked that it exists) for any function not marked with #[no_split_stack]?

(NB. I have no understanding of the implementation in #9834 at all.)

[alexcrichton]

In theory it's possible, but this can't be a normal language item int he sense that it's required to have #[no_split_stack] and it's also required to very quickly deal with the stack having been overflowed, which without some fun inline assembly and weird dances, will be hard to write in rust.

I do suppose though that a lang item is a nice way to wire this up, but I still like the idea of having a #[no_std] crate "just compile" with fn main(_: int, _: **u8) -> int { 0 } because that's kind of what you expect.

[alexcrichton]

I'm going to close this because I don't believe that there's much to do as a result of this. This attribute "just working" depends on having a solution for whether the __morestack prologue should be present or not. We have chosen for now for this to always be there, so I think that this is essentially working as intended.

[thestinger]

It still doesn't work, though. It's not possible to use freestanding Rust without using clang as the backend. This isn't the only problem, another is that Rust provides no way to mark external functions as not throwing and then inserts calls to the segmented stack adjustment call.

[alexcrichton]

I'd recommend opening up more specific issues for those problems, I don't think this "it doesn't work" blanket issue works very well for tracking progress.

[thestinger]

I don't think metabugs are very useful either, but I'm not sure what the specific solution to these problems should be.

[brson]

Is there a followup to this issue?

[thestinger]

#11871 blocks using rustc to compile freestanding/runtimeless code itself without using clang or llc near the Rust version. Rust doesn't install either of these and adding a step to building is quite annoying.

#10780 blocks using static linking rather than link-time optimization.

#10116 is an annoyance forcing the extra step of building a separate crate with memcpy, memmove and memset.