On Mon, Oct 21, 2013 at 12:28 PM, Alex Crichton <a...@crichton.co> wrote: > It's great to see progress in this area! I know that this has been a > tricky topic in the past, and it would be awesome to get things sorted > out. > > One thing I would keep in mind is that pretty much any strategy > (except the no safety one) involves changes in LLVM.
The only change I can see necessary is querying the maximum stack frame size (for guard zones). Daniel mentioned this in IRC yesterday. > I think we all > hope to one day use "clean upstream LLVM" as opposed to maintaining > our own fork. This sounds like it's functionality which would > certainly be desirable from LLVM's point of view, but it may be worth > checking up with them occasionally to ensure so. Recently they're not > big fans of the idea of a "no-split-stack" attribute, which I thought > was a given. > > Another thing to consider is that in a runtime-constrained context, > you're probably not going to want to use the default implementation of > the "stack safety mechanism" in place. Right now this means that you > probably don't want libmorestack.a and it's __morestack strategy. So the crate would use a different value for `#[stack_safety="...];`, rather than `#[stack_safety="segmented"];` The idea isn't to enable different implementations of __morestack, the idea is to enable entirely different concepts of stack safety entirely. _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
