Exception causing insns in delay slots

[David S. Miller]

   From: Jason Merrill <jason@redhat.com>
   Date: Fri, 26 Apr 2002 12:45:48 +0100
   
   > Even if it could emit the notes properly, we couldn't unwind to
   > the sucker correctly.  This is because of all the "current->ra - 1"
   > buisness and the assumption (which you mentioned) of the code stream
   > being linear.
   
   This is what I don't understand.  The current->ra - 1 business should give
   us the trapping instruction, which is what we want.  The only way the
   non-linearity would be a problem for a delayed trapping insn would be if
   the unwind info were different before and after (numerically) the call insn,
   which I don't think can happen.

Consider a signal on a null pointer dereference in a delay
slot on Sparc.

Here is the sequence of events:

	b	label
EXCEPTION_BEGIN_LABEL:
	 ld	[%g0], %g2
EXCEPTION_END_LABEL:
...
label:	/* some more code goes here */

We trap, take a SIGSEGV, this lands us eventually in the
frame unwinder.  The kernel provides us with the two
program counter values PC (equal to the LOAD instruction)
and NPC (equal to 'label').

We have to advance PC, and the only valid way to do that
is "PC = NPC".  PC + 4 is not the next instruction we would
execute.

This new PC value is 'label' and 'label' - 1 is likely not in the load
instruction and therefore not in the exception region.

Are you suggesting I just ignore NPC and set PC to "PC + 4" instead?
Hmmm... ok, but does PC need to be accurate for other purposes?