sigaltstack and cygwin

Stephen Weeks MLton@sourcelight.com
Fri, 1 Mar 2002 12:38:05 -0800


> In linux, %esp holds the C stack immediately before a C call and
> shortly thereafter.  Also, %esp holds frontier at every basic block
> boundary that isn't a a C call.  Otherwise, it's free to do what it
> wants.

Ahh.  I thought that because of the way the Linux kernel handled
signals that we had to do more.  Namely, that we had to ensure that
%esp never accidentally looked like it was pointing to the alternate
signal stack.  But now I remember that Henry's hack of allocating some
extra space below the region used as the signal stack (as passed to
sigaltstack) removes this restriction.  So, in linux, there is no
restriction imposed on %esp due to signal handlers.  Right?

> > Cygwin has no sigaltstack.  So, it seems to me that I need to change
> > the x86-codegen so that %esp is reserved to hold the C stack pointer
> > when targeting cygwin.  Does that seem right?  Easy?
> 
> That shouldn't be too hard.  Essentially, you or I'll need to muck with
> x86-generate-tranfers.fun.  It should suffice to simply put an
> x86.Directive.Assume of esp in c_stackP with reserve = true at the top of
> every basic block when compiling with cygwin.  Also, change x86codegen.h
> to set up whatever register conventions we want for that arch.

It looks like there are some hardwired constants (transferRegs,
frontier) that will need to be defined conditionally on whether this
restriction is being imposed.  I also see the following in lots of
places
             Assembly.directive_assume
	     {assumes
	      = [{register = stackTopReg,
		  memloc = stackTop (),
		  weight = 1024,
		  sync = false,
		  reserve = false},
		 {register = frontierReg,
		  memloc = frontier (),
		  weight = 2048,
		  sync = false,
		  reserve = false}]},

Basically, I was thinking to add one more element to the assumes list
for esp=cstackp (and changing frontierReg to some other register (any
recommendations?)).  Since you think it looks simple, I'll give it a
try, probably tomorrow though.
 
> We'll lose some performance due to extra spilling with less registers.

Right.  So my optimization still makes sense here -- only impose the
restriction on programs that install signal handlers.  Some earlier
pass in the backend will set a flag to true iff we are compiling for
cygwin and the program uses signals handler.  The code in
x86-generate-transfers will test this flag when setting up the
assumes.