------- Comment #10 from rth at gcc dot gnu dot org 2006-02-21 18:47 ------- (In reply to comment #8) > This is what I have so far (libjava not done yet)
The patches so far look fine. > but I'm not sure a simple CIE flag isn't sufficient on all arches. You're confounding two different problems: (1) How to unwind from a signal, at whatever point the signal is delivered, and (2) How to recognize a given signal within an exception handling region. Problem 1 is we arrive at the signal handler with the PC set somewhere. We assume that the insn at the PC is the next insn to be executed, and that all previous insns have already been executed. This is as true of SIGFPE as any other signal. Problem 2 is that the SIGFPE may be deliviered much later than the insn that caused the signal. This is particularly obvious with 80387, in that it may not be delivered until the next FP insn. The only reason we might want to care about this problem is if we wish to turn the signal into an exception, and send that to a surrounding catch handler. This is not the problem we're trying to solve in this PR. Frankly, I'm not too concerned about solving it ever; it requires changes to code generation to solve properly, and I've seen no one actually request it. If anyone would have wanted it, I would have expected Java, but Java runs with all FP excptions masked. > This is most important for libjava, as libjava is doing ugly hacks around this > problem and thus should know if S flag will be used or not. In i386 case we > are fine, libjava calls sigaction syscall directly and sets SA_RESTORER, so > sigreturn pad in libjava is used. Alpha could use the same trick Yep. > MD_FALLBACK_FRAME_STATE_FOR is under GCC's control, but on ppc/ppc64 we are > in trouble when using approx. November 2005 till now kernels (before that > there was no vDSO on ppc{,64}). Will these kernels refuse the sa_restorer field? I see that ppc does have such a field... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26208