------- Comment #17 from jakub at gcc dot gnu dot org 2006-02-22 08:11 ------- The nop before the signal trampoline is needed for similar reason, but one signal frame lower. A normal signal frame lower in the stack will contain the exact address of the start of the trampoline (or in unusual cases another signal frame will contain some address within the trampoline's range if a thread has been signalled while executing the few trampoline instructions). That's not what is being addressed in this PR, FDE for the trampoline simply can start 1 (or more) bytes before the trampoline and there is a limited number of trampolines (the dynamically created ones are always handled by MD_FALLBACK_FRAME_STATE_FOR). This PR is about PC stored in the signal frame and used when handling the bottommost frame above the signal frame.
As for PPC vDSO, if you have a spare register slot in the 0 .. DWARF_FRAME_REGISTERS range, you can certainly try to do the same as the S flag is doing. In MD_FALLBACK_FRAME_STATE_FOR it is doable (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). Doing it in vDSO's .eh_frame might be far more difficult, remember that DW_CFA_expression returns address where a register is stored and there is no DW_CFA_expression_value that would be able to compute arbitrary register values and leave it on unwinder implementation to find a memory slot into which to store the value during unwinding. I don't think there are any means to store some value into certain address in .eh_frame either, so you'd need to modify kernel to store both PC and PC+1 into the sigcontext at handle_signal time and the .eh_frame to use it. Doable, but it doesn't buy you anything over just adding S flags. In both cases were are trouble with libjava when using kernels since vDSO was added till either S flag is added to the vDSO .eh_frame, or the above described ugliness is implemented in the kernel. In libjava/include/*-signal.h we need to know how will signal frame unwinding work. On most architectures we know that - MD_FALLBACK_FRAME_STATE_FOR is used and we control both M_F_F_S_F and *-signal.h in the same tree. On some architectures it is under glibc or kernel control (i386, alpha), but *-signal.h can override it, force use of M_F_F_S_F or provide its own unwind info. But on ppc it used to be M_F_F_S_F, but since November it is in kernel's hands and libjava cannot override. As the S flag doesn't affect older libgcc's, the only thing that will not work is GCC (libgcc+libgcj particularly) after (if) these patches make it in with kernel between November and now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26208
