Exception causing insns in delay slots

[Jason Merrill]

>>>>> "David" == David S Miller <davem@redhat.com> writes:

>    From: Jason Merrill <jason@redhat.com>
>    Date: Fri, 26 Apr 2002 12:15:30 +0100

>> Ok, this seems to doubly confirm the need for my reorg fix.
   
>    I wouldn't expect trapping instructions to have any unwind information
>    impact, except that the unwind info needs to be correct when we reach them.
>    This would only be a problem if the trapping insn is scheduled in the
>    delay slot of an insn which adjusts the stack.  I could imagine that being
>    true of some sort of combined call-push insn, but I'm not aware of any such
>    beast, certainly not on a target with delay slots.

> We don't emit the notes properly.  When reorg puts an exception
> causing instruction into a delay slot, and that instruction is the
> only exception causing instruction in that particular exception
> region, we currently don't emit the notes correctly.  My original
> email of this thread shows the details around this.

Right, I agree that your patch is a good short-term fix to the problem of
not properly finding the exception region for an insn in a delay slot, due
to the notes being in the wrong place.

> 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.

Jason