sh: Don't continue unwinding across interrupts
authorMatt Fleming <matt@console-pimps.org>
Sat, 30 Jan 2010 17:36:20 +0000 (17:36 +0000)
committerPaul Mundt <lethal@linux-sh.org>
Mon, 8 Feb 2010 01:47:04 +0000 (10:47 +0900)
commit944a3438615da65f11e2559840404a2cac5f65ea
tree44b77dbb19ee1ac55d0a9d7c174e1ef04dcf6f71
parent1dca56f13899b9e256f56198026019835aaf9a3a
sh: Don't continue unwinding across interrupts

Unfortunately, due to poor DWARF info in current toolchains, unwinding
through interrutps cannot be done reliably. The problem is that the
DWARF info for function epilogues is wrong.

Take this standard epilogue sequence,

80003cc4:       e3 6f           mov     r14,r15
80003cc6:       26 4f           lds.l   @r15+,pr
80003cc8:       f6 6e           mov.l   @r15+,r14
<---- interrupt here
80003cca:       f6 6b           mov.l   @r15+,r11
80003ccc:       f6 6a           mov.l   @r15+,r10
80003cce:       f6 69           mov.l   @r15+,r9
80003cd0:       0b 00           rts

If we take an interrupt at the highlighted point, the DWARF info will
bogusly claim that the return address can be found at some offset from
the frame pointer, even though the frame pointer was just restored. The
worst part is if the unwinder finds a text address at the bogus stack
address - unwinding will continue, for a bit, until it finally comes
across an unexpected address on the stack and blows up.

The only solution is to stop unwinding once we've calculated the
function that was executing when the interrupt occurred. This PC can be
easily calculated from pt_regs->pc.

Signed-off-by: Matt Fleming <matt@console-pimps.org>
Signed-off-by: Paul Mundt <lethal@linux-sh.org>
arch/sh/kernel/dwarf.c