------- Comment #18 from uweigand at gcc dot gnu dot org 2006-02-22 09:57 ------- (In reply to comment #17)
> (e.g. s390/linux-unwind.h was doing that, although just for 2 selected > signals, which wasn't good enough, as e.g. all async signals need to be > handled the same). We've actually taken quite a bit of care to ensure that the position of the PC on s390 can be understood deterministically in all cases. The synchronous signals come in two flavours: - SIGSEGV and SIGBUS: here the PC points back to the instruction that we attempted and failed to execute -- returning from the signal handler would by default re-execute the failed instruction - SIGILL, SIGFPE, and SIGTRAP: here the PC points after the instruction that caused the signal condition to be raised -- returning from the signal handler would by default simply continue after that instruction For all asynchronous signals, the PC points to the first instruction we have not executed yet -- returning from the signal handler thus continues execution with that instruction. So you *need* to handle signals differently depending on what signal it is -- I'm not sure I understand why you want to remove that. What we currently have definitely works correctly for all synchronous signals on s390. As for asynchronous signals, I guess it depends on what you want to see happen here -- I'm not sure what it means to throw an exception from within an asynchronous signal handler. For unwinding purposes, I guess I can see why you would want the next instruction to show up in the backtrace, so I wouldn't mind changing the if (signal == SIGBUS || signal == SIGSEGV) to if (signal != SIGILL && signal != SIGFPE && signal != SIGTRAP) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26208
