I tried to adapt fix-stub_segv-stack.patch to my s390.
Unfortunately sigreturn on s390 needs to have the address
of the entire signal-stackframe in r15. What is given to the
handler as a param is a pointer to the sigcontext only.
stackframe contains some space for handler's register saving
_before_ sigcontext.
So I thought about avoiding the sigreturn at all. Working on
this I found out some small points:

- there is a bug (typo) in wait_stub_done()

- stopping stub_segv_handler with a "breakpoint" without
   calling sigreturn, lets SIGSEGV being blocked after that.
   At the next SIGSEGV, I see stub_wait_done() calling panic
   just as with Rob's problem. And I see the child being gone!
   I understand, that the host unblocks SIGSEGV and sets the
   handler to SIG_DFL. But I don't understand, why the child
   already is gone after the waitpid(), without resuming it.
   I guess, this is the reason for Rob not being able to debug
   the problem.
   Thus I added SA_NOMASK to the flags for the handler.

- I changed the additional mask for the handler to be empty.
   The only exception is x86_64, that currently must use sigreturn
   and therefore still masks SIGUSR1 while the handler runs.
   In skas, userspace shouldn't receive SIGIO or SIGWINCH (I hope
   I'm right here?), SIGVTALRM already is handled by wait_stub_done.
   Then I changed i386's stub_segv_handler to stop using "int3"
   immediately after saving faultinfo.
   This new method saves some syscalls on i386 and s390 and
   simplifies s390.

All three patches are attached. They are tested in i386 and s390,
for me they work fine. I hope, the patches don't break x86_64.
Unfortunately I can't test that.
If there would be a solution for the RCX problem on x86_64, I would
prefer to use the "int3" this subarch also, making the nasty
ARCH_STUB_SEGV_MASK_SIGNAL macro obsolete.

	Bodo