On Fri, Feb 01, 2019 at 01:38:05PM -0800, Doug Anderson wrote:
> Hi,
>
> I was wondering if anyone out there has given any thought to
> annotating the ARM64 IRQ handling in such a way that we could stack
> crawl past el1_irq() when in gdb.
>
> I spent a bit of time on this a few months ago and documented all my
> findings in:
>
> https://bugs.chromium.org/p/chromium/issues/detail?id=908721
>
> I can copy and paste all the discussion from that bug here, but since
> it's public hopefully folks can read the discussion / investigation
> there. To put it briefly, though: I can stack crawl past "el1_irq"
> with the normal linux stack crawl (which is what kdb uses) but I can't
> crawl past "el1_irq" in gdb(). After talking to some of our tools
> guys here I'm fairly certain that we could solve this with the right
> CFI directives, but when I poked at it I wasn't able to figure out the
> magic.
>
>
> Anyway, I figured I'd check to see if anyone here happens to know the
> right magic.
The kernel (appears to) generate a valid frame record for el1_irq:
0xffffff8008082b94 <+84>: mrs x22, elr_el1
[...]
0xffffff8008082ba0 <+96>: stp x29, x22, [sp, #304]
0xffffff8008082ba4 <+100>: add x29, sp, #0x130
(I note that 0x130 == 304. Yay binutils.)
>From the bug report, I don't see any real investigation into what
precisely causes gdb to choke on this frame.
Do you have evidence that CFI annotations help in this case? And can
you explain _why_ they help (i.e., precisely how is gdb relying on the
annotations)?
Cheers
---Dave
_______________________________________________
Kgdb-bugreport mailing list
Kgdb-bugreport@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/kgdb-bugreport
