unwind_stack() and an exception at the last instruction (after the epilogue)

["Dmitry Adamushko" <dmitry.adamushko@gmail.com>]

[ resend: probably, my previouse one had been rejected as it was not
in plain-text :]


 Hello,

 unwind_stack() explicitly handles a case when an exception takes
place at the first instruction, i.e. before the prologue.

 But what's about another corner case - when an exception is caused by
an instruction placed after the epilogue.

 example:

 00400e8c <cause_oops>:
   400e8c:       3c1c0fc0        lui     gp,0xfc0
   400e90:       279c71c4        addiu   gp,gp,29124
   400e94:       0399e021        addu    gp,gp,t9
   400e98:       27bdffe0        addiu   sp,sp,-32
   400e9c:       afbf0018        sw      ra,24(sp)
   400ea0:       afbc0010        sw      gp,16(sp)
   400ea4:       8f84801c        lw      a0,-32740(gp)
   400ea8:       8f9980ac        lw      t9,-32596(gp)
   400eac:       00000000        nop
   400eb0:       0320f809        jalr    t9
   400eb4:       24841984        addiu   a0,a0,6532
   400eb8:       8fbc0010        lw      gp,16(sp)
   400ebc:       8fbf0018        lw      ra,24(sp)
   400ec0:       27bd0020        addiu   sp,sp,32
   400ec4:       03e00008        jr      ra
   400ec8:       ac000000        sw      zero,0(zero)
<----------- <epc> will be here when an exception happens


 In this case, <sp> already points to the caller's stack frame so
unwind_stack() will take a wrong assumption (as it looks at the
epilogue of the callee).

 btw, the first and last instructions are just corner cases of an
instruction being placed before the prologue and after the epilogue,
right?

 so something like

 - if (unlikely(ofs == 0)) {
 + if (unlikely(offs == 0 || offs == size - sizeof_mips_instruction))
         pc = *ra;
         *ra = 0;
         return pc;
 }

 won't be a generic solution.

 Did I miss something? Hm... <epc> is always guaranted to be right
when the instruction is in the branch delay slot?

 p.s. yep, the example is a part of user-space code (optimization:
-Os) or is there anything (compiler options etc.) preventing similar
code from being generated for kernel-space code?


Thanks in advance for any comments.


-- 
Best regards,
Dmitry Adamushko