mikros/rust
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

libnative should not mess with stack limits in the TIB. Only libgreen has a legitimate need to set them.

Browse Source
This commit is contained in:
Vadim Chugunov 2014-07-05 00:47:09 -07:00
parent bf420e58c2
commit bf76e00231
2 changed files with 8 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
src/libgreen/context.rs
View File

@ -105,11 +105,11 @@ impl Context {
// invalid for the current task. Lucky for us `rust_swap_registers`
// is a C function so we don't have to worry about that!
match in_context.stack_bounds {
Some((lo, hi)) => stack::record_stack_bounds(lo, hi),
Some((lo, hi)) => stack::record_stack_bounds_green(lo, hi),
// If we're going back to one of the original contexts or
// something that's possibly not a "normal task", then reset
// the stack limit to 0 to make morestack never fail
None => stack::record_stack_bounds(0, uint::MAX),
None => stack::record_stack_bounds_green(0, uint::MAX),
}
rust_swap_registers(out_regs, in_regs)
}

7
src/librustrt/stack.rs
View File

@ -125,7 +125,7 @@ extern fn stack_exhausted() {
}
#[inline(always)]
pub unsafe fn record_stack_bounds(stack_lo: uint, stack_hi: uint) {
pub unsafe fn record_stack_bounds_green(stack_lo: uint, stack_hi: uint) {
// When the old runtime had segmented stacks, it used a calculation that was
// "limit + RED_ZONE + FUDGE". The red zone was for things like dynamic
// symbol resolution, llvm function calls, etc. In theory this red zone
@ -154,6 +154,11 @@ pub unsafe fn record_stack_bounds(stack_lo: uint, stack_hi: uint) {
}
}
#[inline(always)]
pub unsafe fn record_stack_bounds(stack_lo: uint, _stack_hi: uint) {
record_sp_limit(stack_lo + RED_ZONE);
}
/// Records the current limit of the stack as specified by `end`.
///
/// This is stored in an OS-dependent location, likely inside of the thread