alternate stacks for signal handlers

[Matthew Fluet]

> Excellent  bug tracking.  Looking at the Linux kernel source, I'm still a bit
> nervous about the alternate stack stuff.  It seems that the kernel decides if
> you  are  already  using  the alternate stack by looking at the current stack
> pointer.  If this is true, then it means that you can't use the stack pointer
> register  as  a general purpose register.  If it just so happens to contain a
> value which looks like a pointer into the alternate  stack  then  the  kernel
> concludes  that  it  is  already in the alternate stack and doesn't reset the
> stack pointer.  This  is  really  horrible,  and  instead  the  kernel  could
> maintain  a  flag  (really  a  counter)  if  it  has  already switched to the
> alternate stack.  I don't know what SML/NJ does.  At any rate, this shouldn't
> be  a  problem  if  you always have a pointer to some other data in the stack
> pointer register.

I think we should be o.k. with using the stack pointer.  Most of the time,
%esp will look like gcState.frontier.  It will be a pointer into memory
and potentially memory "near" to where I mmaped the alternate signal
stack.  But, if the kernel is just doing a range check, that will be fine.
Just before a C-call, %esp is restored to the original C-stack pointer.
After a C-call, %esp is used more as a general purpose register.
Immediately after the call, it will still point to the C-stack, but the
register allocator is free do do anything it wants with it.  I don't
immediately re-cache gcState.frontier, because sometimes we get a lot of
C-calls in a row (particularly for IO) and we end up shuffling values into
and out of memory for no reason.

I guess there is a small chance that %esp could end up being a value that
happens to fall into the alternate signal stack range.  But, I think that
falls back on the original point that the kernel should really track
whether or not it is currently handling a signal or not.