[ 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