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

Author: vadimcn

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)
         }

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