Another option is to use an ICE or JTAG controller, and GDB. This ‘hardware’ solution is especially used with embedded systems.
But for instance QEMU offers similar features:
start QEMU with a GDB ‘remote’ stub which listens on ‘localhost:1234’ :
qemu -s ...
,then with GDB, you open the kernel file
vmlinux
compiled with debug information (you can take a look a this mailing list thread where they discuss the unoptimization of the kernel).connect GDB and QEMU:
target remote localhost:1234
see your live kernel:
(gdb) where #0 cpu_v7_do_idle () at arch/arm/mm/proc-v7.S:77 #1 0xc0029728 in arch_idle () atarm/mach-realview/include/mach/system.h:36 #2 default_idle () at arm/kernel/process.c:166 #3 0xc00298a8 in cpu_idle () at arch/arm/kernel/process.c:199 #4 0xc00089c0 in start_kernel () at init/main.c:713
Unfortunately, user-space debugging is not possible so far with GDB (no task list information, no memory management unit reprogramming to see different process contexts, …), but if you stay in kernel-space, that’s quite convenient.
info threads
will give you the list and states of the different CPUs
You can get more details about the procedure in this PDF: