Re: safety of GCJ-generated code

[Andrew Haley <aph at cambridge dot redhat dot com>]

[I hit "send" too soon.  Sorry.]

Andrew Haley writes:
 > Adam Megacz writes:
 >  > 
 >  > Interestingly, in my mucking around with the win32 stuff, I though I
 >  > saw something about a special "Stack Overflow Signal" on
 >  > win32... perhaps it might be as simple as just catching that signal
 >  > and then "throw new StackOverflowException()"...
 > 
 > Erm, but you'd have no stack to call new().  :-)
 > 
 > However, given that simply receiving a signal requires stack space to
 > be allocated in order to save the user context, I assume that a kernel
 > must unprotect the guard area at the end of a thread's stack before
 > sending the signal?  Hmm, I need to have a chat with a kernel
 > engineer.

Right, I have now done so, and I have found out what is needed for
Linux.

Unless you set up an alternative signal stack then if there's no space
for the user context on the your stack the kernel will force your SEGV
handler to SIG_DFL and send you another SEGV, which will kill your
process immediately.

So, for Java we should use sigaltstack(2) for our SEGV handler.  This
delivers signals on a separate signal stack.

Perhaps we'll then have to find a way to switch back on to the stack
that has overflowed in order to throw the exception.  On the other
hand, perhaps we won't: the unwinder may Just Work even through a
handler that uses an altstack.  I presume that we can arrange things
so that more SEGVs will not be delivered while we're still on the
altstack.
 
I don't know what to do for other OSes, but I guess it's similar.

Andrew.