Exception causing insns in delay slots

Fri Apr 26 04:45:00 GMT 2002

 From: Jason Merrill <jason@redhat.com>
 Date: 2002年4月26日 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.
That is the problem.
The safe fix for that is the reorg changes.
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.
Tell me which part isn't making sense and I'll try to elaborate
further.