Debug kernel panic with gdb?

[arvid.brodin@enea.com (Arvid Brodin)]

Arvid Brodin wrote:
> Hi,
> 
> I'm trying to debug a kernel panic (something like this):
> 
> Unable to handle kernel NULL pointer dereference at virtual address 00000014
> ptbr = 93959000 pgd = 93a0a000
> Oops: Kernel access of bad area, sig: 11 [#1]
> FRAME_POINTER chip: 0x01f:0x1e82 rev 2
> Modules linked in: ftdi_sio usbserial
> PC is at isp1760_irq+0xda/0x7f0
> LR is at isp1760_irq+0x492/0x7f0
> pc : [<901408be>]    lr : [<90140c76>]    Not tainted
> sp : 93aa399c  r12: fffffffe  r11: 00000000
> r10: 00000000  r9 : fffffffe  r8 : 00000000
> r7 : 93aa3a08  r6 : 93406400  r5 : 00820004  r4 : 00000003
> r3 : 00000008  r2 : 00000002  r1 : fffffffd  r0 : 93837000
> 
> Call trace:
>  [<90134abc>] usb_hcd_irq+0x50/0x54
>  [<900383da>] handle_IRQ_event+0x1e/0x40
>  [<90039098>] handle_level_irq+0x78/0x8c
> ...
> 
> This is on an AVR32 platform, and I'm building the kernel myself (cross
> compiling). The image is then converted to a uImage before being loaded
> to the target. Is there a way to get the following to work in this context?
> 
> $ gdb arch/avr32/boot/images/vmlinux.elf 
> ...
> Reading symbols from /home/.../linux-2.6.37/arch/avr32/boot/images/vmlinux.elf...done.
> (gdb) list *isp1760_irq+0xda
> 0x9017ac36 is in isp1760_irq (include/linux/spinlock.h:285).
> 280		raw_spin_lock_init(&(_lock)->rlock);		\
> 281	} while (0)
> 282	
> 283	static inline void spin_lock(spinlock_t *lock)
> 284	{
> 285		raw_spin_lock(&lock->rlock);
> 286	}
> 287	
> 288	static inline void spin_lock_bh(spinlock_t *lock)
> 289	{
> 
> 
> The problem is that the line reported is totally wrong (this being very unhelpful
> and confusing indeed - it tool me awhile to realise this!). I've also tried to
> use gdb from the avr32 toolchain with the same result.
> 
> Is there a way to get this to work?
> 
> Thanks,
> Arvid Brodin
> Enea Services Stockholm AB

To reply to my own email, the problem probably has to do with the fact that the
kernel is built with optimization. Modifying KBUILD_CFLAGS in the Makefile to 
specify -O1 made things a lot better (although you still cannot rely completely
on the line number reported). Unfortunately, the kernel won't build with -O0.

-- 
Arvid Brodin
Enea Services Stockholm AB