Re: safety of GCJ-generated code

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

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.

Righ, 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 cuser ontext on the your stack the kernel will force your SEGV
handler to SIG_DFL and send you another, which will kill your process
immediately.

So, we should use sigaltstack(2) for our SEGV handler, and perhaps
we'll then have to find a way to switch back on to the thread that has
overflowed in order to throw the execption.  On the other hand,
perhaps we won't: the unwinder may Just Work.  I presume that we can
fix it so that more SEGVs will not be delivered while we're still on
the alternate signal stack.
 
I don't know what to do for other OSes, but I guess it's similar.

Andrew.