Notes on stack overflow protection.

Two options: guard page or explicit test.

Using a guard page is better because there is zero cost in the normal (no
overflow) case.  So we use it if at all possible.  The only machine we
might have to do an explicit test on is the RT.  There we could just use a
conditional trap.  (Or not worry about it.)  Either way, lets assume the
trap gets mapped into a signal.

When the control stack limit is overflowed, a temporary control stack limit
is established and the debugger invoked.  If the top level REP ever notices
that there is a temporary control stack limit in effect that is different
from the real control stack limit, it resets the control stack limit and
prints a warning to this effect.

When the debugger is invoked due to a control stack limit, the CONTINUE
restart will set the real control stack limit to the temporary control
stack limit in effect at that time (i.e. sanctify it) and continue
execution.  Throwing to the top level (or using any other restart) will
leave the temporary control stack limit in effect until %TOP-LEVEL gets a
chance to change it back.  We can't change it back ourselves because we are
executing on the part of the stack that we want to protect.

If we find that leaving the stack limit extended until we return to the top
level, we could have the lisp handler look something like:

	(defun handle-stack-overflow ()
	  (let ((okay nil))
	    (unwind-protect
		(progn
		  (cerror "Extend the stack." "Stack overflowed")
		  (sanctify-stack-extension)
		  (setf okay t))
	      (unless okay
		(setf stack-limit (current-cfp))))))

That way the stack limit will only be quietly grown a small amount.


Other issues: the other two stacks.

The binding stack can be delt with in exactly the same way, if we want to.
The only way the binding stack could overflow without overflowing the
control stack is to call progv with a very long (or circular) list.  Not
too likely, so I say don't bother.

The C stack is much harder.  It we protect any of it, we have to establish
a signal stack to make sure we can actually take the signal upon overflow.
Then we have to worry about all the additional problems caused by using a
signal stack.  Doesn't seem worth the bother to me.