From bf76e0023114fb47cc8fc766dc2f3d5db8c696a2 Mon Sep 17 00:00:00 2001 From: Vadim Chugunov Date: Sat, 5 Jul 2014 00:47:09 -0700 Subject: [PATCH] libnative should not mess with stack limits in the TIB. Only libgreen has a legitimate need to set them. --- src/libgreen/context.rs | 4 ++-- src/librustrt/stack.rs | 7 ++++++- 2 files changed, 8 insertions(+), 3 deletions(-) diff --git a/src/libgreen/context.rs b/src/libgreen/context.rs index 45f41181bf8c7..d681e53af42d5 100644 --- a/src/libgreen/context.rs +++ b/src/libgreen/context.rs @@ -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) } diff --git a/src/librustrt/stack.rs b/src/librustrt/stack.rs index 6544c020e0949..a79f453cf1ecb 100644 --- a/src/librustrt/stack.rs +++ b/src/librustrt/stack.rs @@ -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