On Mon, Oct 21, 2013 at 1:08 PM, Kevin Ballard <[email protected]> wrote: > On Oct 21, 2013, at 9:11 AM, Corey Richardson <[email protected]> wrote: > >> On Mon, Oct 21, 2013 at 11:48 AM, Patrick Walton <[email protected]> wrote: >>> This seems generally on the right track. A couple of thoughts: >>> >>> * I can pretty much guarantee you that that simple of a static analysis to >>> determine stack size is going to fail on any reasonable program. I would >>> just leave it out. If you're feeling ambitious, you could implement it as an >>> LLVM pass to eliminate stack bounds checks on recursion-free leaves of the >>> call graph. (LLVM is the right place to do it, as it can make these >>> decisions post-inlining, and also knows the exact amount of stack space each >>> function takes up.) >>> >> >> Yep. It's mostly for the case where recursion and dynamic dispatch is >> going to be denied, which seems to be the case for some >> embedded/realtime contexts, afaict from the available research. > > It seems to me that trying to determine max stack size is incompatible with > dynamic linking. So even if you disallow recursion, any function that calls a > function outside of its own crate is not going to be able to trust its > calculated max stack size.
The stack limit would be in the crate metadata, but I can see how it'd be possible to violate safety with this. But in the cases you'd want this analysis, you wouldn't be using dynamic linking anyway. _______________________________________________ Rust-dev mailing list [email protected] https://mail.mozilla.org/listinfo/rust-dev
