Re: Exception causing insns in delay slots

[Jason Merrill <jason at redhat dot com>]

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

>    The dwarf2 unwind information does not know about delay slots; it assumes
>    that code is executed linearly, so it's important that the shuffling of
>    instructions for delay slot scheduling doesn't affect register save
>    information.  Other than that, it should be fine.
   
> 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.

The problem with delay slots and dwarf2 has more to do with scheduling a
stack adjustment into the delay slot of a call which throws.  Some
discussion of this WRT the PA:

  http://gcc.gnu.org/ml/gcc-patches/2002-01/msg00209.html
  http://gcc.gnu.org/ml/gcc-patches/2002-04/msg00169.html

the upshot of which seems to be that the PA now suppresses scheduling of
prologue insns into the body to avoid the above.  I would think that a
better fix long term would be to recognize delay slot patterns in
dwarf2out.c, and emit dwarf2 info which pretends that the adjustment in the
delay slot actually happens after the instruction numerically preceding the
call.

Jason