On Mon, Jun 27, 2011 at 04:53:06PM +0400, Dmitry Eremin-Solenikov wrote:
I've got into a problem when trying to debug irq handlers on PXA (in
qemu). backtrace is really strange from my POV (a target is just a qemu
running a bit modified 3.0-rc2 kernel):
...
Breakpoint 1, handle_level_irq (irq=42, desc=0xc3e06000) at kernel/irq/chip.c:329
329 mask_ack_irq(desc);
(gdb) bt
#0 handle_level_irq (irq=42, desc=0xc3e06000) at kernel/irq/chip.c:329
#1 0xc0085f64 in generic_handle_irq_desc (irq=42) at include/linux/irqdesc.h:111
#2 generic_handle_irq (irq=42) at kernel/irq/irqdesc.c:304
#3 0xc0033060 in asm_do_IRQ (irq=42, regs=<value optimized out>) at arch/arm/kernel/irq.c:90
#4 0xc0033b50 in __irq_svc () at arch/arm/kernel/entry-armv.S:202
#5 0xc0033b50 in __irq_svc () at arch/arm/kernel/entry-armv.S:202
#6 0xc0033b50 in __irq_svc () at arch/arm/kernel/entry-armv.S:202
#7 0xc0033b50 in __irq_svc () at arch/arm/kernel/entry-armv.S:202
#8 0xc0033b50 in __irq_svc () at arch/arm/kernel/entry-armv.S:202
#9 0xc0033b50 in __irq_svc () at arch/arm/kernel/entry-armv.S:202
#10 0xc0033b50 in __irq_svc () at arch/arm/kernel/entry-armv.S:202
#11 0xc0033b50 in __irq_svc () at arch/arm/kernel/entry-armv.S:202
#12 0xc0033b50 in __irq_svc () at arch/arm/kernel/entry-armv.S:202
... and so on it continues ad infinitum. Is it the expected behaviour?
Because I'm pretty much sure that this isn't a desired behaviour.
My guess is that gdb is trying to unwind using the unwind information.
However, I don't think we actually give the assembler the full information
to be able to unwind this. I've no idea how to solve this as I'm no
expert at the debug info.
We _really_ _do_ want to unwind through this so that we can see the
parent kernel context information in backtraces - and the fact that
the kernel itself can unwind through these means we can't tell the
unwinder not to.
So, no idea. I think you need someone who knows debug info to sort
this one out.