Re: Exception causing insns in delay slots

[Jason Merrill <jason at redhat dot com>]

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

>    After some analysis of how unwinding and throw work, I think it
>    may not even be supportable on Sparc.  The reason has to do with
>    a combination of two things:

>    a) How unwind-dw2.c looks for FDEs at "context->ra - 1" instead of
>       just "context->ra"

>    b) How on delay slot architectures "context->ra - 1" is not
>       necessarily the previous instruction executed.

context->ra - 1 isn't supposed to be the previous instruction; it's
supposed to point somewhere inside the throwing instruction.

>    Basically, for signal frame dwarf2 unwind to work in the current
>    framework the signal handler advances the program counter past
>    the exception causing instruction and that value minus one has to
>    be within the exception causing instruction.

Sounds right to me.  What's the problem?

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.

Jason