Fix KGDB backtrace on ARM

[wma]

Summary

Modify trapframe decoding to properly analyze trapframe.

Provide method for fixup_pc. It happens, that in some kernel
functions, the GDB stack frame decoder cannot determine both
func name and frame size. This is because these functions
either contain invalid instruction, or their format does
not match standard schema. Detect that scenarios and move
PC accordingly to jump into known function schema, which
GDB is able to parse.

[kib]

Did you tried to upstream this, or at least add the patch to jhb' collection of the pending gdb patches.

In-tree gdb probably have not a bright future, unfortunately.

gnu/usr.bin/gdb/kgdb/trgt_arm.c

275 ↗

(On Diff #15257)

A comment about mask/value of the bits should be made. In fact, I do not understand why do you exclude bits 29 and 27 from the comparision. What is the instruction set which you are trying to catch there ?

[wma]

No, I didn't try to upstream this by any means. It's just some KGDB hacks and I'm not sure if these are generic enough to be pushed into GDB core.

gnu/usr.bin/gdb/kgdb/trgt_arm.c

275 ↗

(On Diff #15257)

Sure, I'll add a comment. Basically, I want to match a non-linked branch instruction. It seems I should mask it with 0xfa000000, thanks.

[kib]

gnu/usr.bin/gdb/kgdb/trgt_arm.c

275 ↗

(On Diff #15257)

I still do not understand the mask. According to the table "A5-21 Branch, branch with link, and block data transfer instructions", the cond must be 0xf, bits 27-26 must have the values "1 0", and the op is 10xxxx. For me, it sounds as if the mask must be 0xff000000, what I miss ?

[wma]

gnu/usr.bin/gdb/kgdb/trgt_arm.c

275 ↗

(On Diff #15257)

No, you're absolutelt right. Im just dumb :) Fixed the mask as it should be, thanks.

[kib]

gnu/usr.bin/gdb/kgdb/trgt_arm.c

290 ↗

(On Diff #15333)

But isn't cond always 0xf for the branch and link instruction ? I.e., why do you compare with 0xEa000000, and not with 0xfa000000 ?

[wma]

gnu/usr.bin/gdb/kgdb/trgt_arm.c

290 ↗

(On Diff #15333)

The cond 0xf is rsvd as per documentation. The "always" condition is 0xe, so that's the case here. See a dump below:

Disasm:
0xc1188198 <panic+28>: str r1, [sp]
(kgdb)
0xc118819c <panic+32>: mov lr, pc
(kgdb)
0xc11881a0 <panic+36>: b 0xc11881a4 <vpanic>
(kgdb)
0xc11881a4 <vpanic>: push {r4, r5, r6, r7, r8, r9, r11, lr}
(kgdb)
0xc11881a8 <vpanic+4>: add r11, sp, #24 ; 0x18

Memory dump:
0xc1188198 <panic+28>: 0xe58d1000
(kgdb)
0xc118819c <panic+32>: 0xe1a0e00f
(kgdb)
0xc11881a0 <panic+36>: 0xeaffffff
(kgdb)
0xc11881a4 <vpanic>: 0xe92d4bf0
(kgdb)
0xc11881a8 <vpanic+4>: 0xe28db018

[wma]

Applied wrong patch last time.