1

I understand the purpose of both kernel and user mode, and how transitions from the former to the latter happen. Yet many sources state that a crash happening in kernel mode is hard to debug and that it should be done remotely, by connecting through telnet for instance (here is an example).

Why is it so hard to debug? Why can’t you just attach a (kernel) debugger to one of the kernel thread and use it the usual way?

qdii
  • 12,505
  • 10
  • 59
  • 116

2 Answers2

4

Crashing in kernel mode can potentially corrupt data structures anywhere in memory, even the debugger itself. Making that bulletproof is hard.

In normal debugging you have two completely isolated processes - the debugger and the thing you're debugging. They're "peers", created equal. The process being debugged can't touch the debugger, no matter what it does (and probably doesn't know it even exists). The debugger on the other hand can interact with the process being debugged in fixed, predictable ways which are always applicable to all regular user processes.

An example: How would you debug the keyboard interface if it's local debugging, or the RS232 code if it's over a serial port? The NIC driver or network stack if it's over a network? Setting a breakpoint in one of those would be unrecoverable because you'd lose access to the device controlling the debugger. Worst case scenario, how would you debug the kernel debugger? With GDB you could, at least theoretically attach a GDB instance to another instance of GDB without too much trouble. In kernel space it's just not possible, because there is no layer above to mediate things.

Flexo
  • 87,323
  • 22
  • 191
  • 272
  • Ok, I think I understand that. Please correct me if I’m mistaken: does that imply that all the processes running in kernel mode share the same address space? And if that is true, is there a reason for that? – qdii Jan 05 '12 at 18:18
  • Yes the kernel address space is shared among all the processes. If you have generic kernel code (not a driver for a specific device) for linux kernel you can use QEMU. You can attach gdb to software running on QEMU, and thus you can step through the kernel code like user code using gdb. But if your code is specific to a device for example a device driver, for which there is no emulation available, your software will not execute. – Saurabh Jan 23 '12 at 10:38
  • @user420536 the question doesn't actually specify Linux or what architecture. There are cases which are very different. – Flexo Jan 23 '12 at 13:24
  • @awoodland -- Certainly there are more kernels in the world than linux kernel. There are two things I have mentioned in my response, a) the address space is shared in kernel for all processes, and it is true for all kernels. b) use of QEMU as an example to attach a debugger to kernel, the way OP wants and its limitations. – Saurabh Jan 25 '12 at 07:30
0

You cannot debug the kernel interactively (or locally) because the kernel itself is in charge even for displaying the picture on the monitor (by communicating with the appropriate display driver) and more than just that. I would put your question in an another way: Is it possible to debug the kernel easier than by connecting through telnet?

To that question my answer is: yes, it is. At least on X86/X64 architectures by using virtualization. I am using VirtualBox to run a guest OS which I can debug on my local machine. I'm also using VirtualKD (http://virtualkd.sysprogs.org/) which speeds up the communication drastically between the debugging machine (the host) and the VM.

The VirtualKD contains a package which modifies the guest Windows' boot.ini thus you can enable debugging at the boot time by selecting the proper menu item which Windows displays to you.

LietKynes
  • 2,953
  • 1
  • 15
  • 10