KDB FAQ

OBSOLETE CONTENT

This wiki has been archived and the content is no longer updated.

What is different about the old KDB vs the merged KDB?

In April 2009 KDB 4.4 (found at: ftp://oss.sgi.com/projects/kdb/download/v4.4/) had significant chunks of the code base removed and hooked it up to the same debug core and polled I/O drivers used by kgdb.

At a really high level, the only difference is how you configure and connect. The kdb disassembler was the main causality of the merger. Architecturally the merged kdb is 99% platform independent and actually gained new features via the debug core API.

Here is a list of the key differences between the out of tree KDB 4.4 and the new merged kdb & kgdb.

The kdb command shell differences

• There are fewer commands in the merged kdb & kgdb.
  • The kdump / kexec analysis modules tools were removed in the process of merging the code bases.
  • The status command emits a bit less information in that you no longer get the exact output you would from cat /proc/meminfo
• The bt command does uses the kernel's backtracer and not a disassembly engine which shows you function arguments
• In the merged kdb & kgdb, presently there is no disassembler (known as the "id" command)
• In the merged kdb & kgdb, when using a non-vga style connection you can transition into kgdb mode and attach gdb, by using the kgdb command.
• The ability to reference elements of a structures was removed. This may get implemented a different way in the future.

Configuration

• Activating kdb is different. NOTE that kbd is short for keyboard.
  • If you want the kernel to stop as soon as possible such that you can install a breakpoint or execute a memory write, you need to add the kgdbwait argument at the end of your kernel boot arguments.
  • Configure kdb for early debugging: earlyprintk=vga ekgdboc=kbd
  • Configure kdb for normal keyboard debugging:
    • Kernel boot arg: kgdboc=kbd
    • At run time: echo kbd > /sys/module/kgdboc/parameters/kgdboc
  • Configure kdb for a serial port at 115200 baud:
    • Kernel boot arg: kgdboc=ttyS0,115200
    • At run time: echo ttyS0,115200 > /sys/module/kgdboc/parameters/kgdboc
  • Configure kdb for a keyboard and the serial port at the same time:
    • Kernel boot arg: kgdboc=kbd,ttyS0,115200
    • At run time: echo kbd,ttyS0,115200 > /sys/module/kgdboc/parameters/kgdboc

• In order to break into the kdb you must use sysrq-g
  • Press and hold the Alt key, and the press and release the SysRq. While still holding alt, press the g key, then release all the keys.
  • OR, use "echo g > /proc/sysrq-trigger"
  • OR, If you are using a serial line send the serial break via your terminal emulator and press g

Number of architectures supported

• KDB 4.4 supported only ia64, x86_64 and i386
• The merged kdb & kgdb supports arm, blackfin, mips, x86_64, i386, sh, powerpc, and sparc.

Internal differences

• The capability to debug before the kernel memory allocator required an 2 stage initialization because the dynamically added commands require the kernel memory allocator.
• The kdb pager was redesigned so as not to rely upon in kernel versions of setjmp() longjmp().
• The kernel's printk can be redirected to a kdb command result.
• kdb command results can be passed to gdb with by using gdb's monitor command. You can try "monitor help" in gdb while connected to kgdb.
• The kdb keyboard driver was refactored to conform to the kgdb I/O driver model and to allow for sending key up events on kernel resume for any keys that were depressed at the time the kernel entered the debugger.
• The kdb breakpoint code was completely overhauled to connect to work in conjunction with the debug core API.
• The debug core gained the ability to change CPU cores without exiting the kernel debug context
• Hardware breakpoint work correctly and are system wide (all cores).

Why merge kdb and kgdb?

One might argue that kdb and kgdb serve fundamentally completely different purposes in life. This is certainly true in the sense that kdb as it stands does not really directly debug source and object files, where as kgdb + gdb do. Also kdb does not require the use of a second system with your object files and source where as kgdb does. BUT, both kdb and kgdb have similar needs in terms of how they integrate into the kernel which is the driving force.

Here is the short list of driving factors in favor of the merge:

• Unite the developers of the kdb an kgdb to improve the overall functionality.
• Have one set of polled I/O drivers for interaction with the kernel debugger
• Once merged, provide the possibility to extended the API for functionality such as Kernel Mode Setting where you can drop into a debug shell from a graphical session
• Some developers want the best of all worlds and want even more power from the gdb connection by allowing the kdb interrogation via gdb's monitor command.
• kdb has long had a long history and quite a number of uses, it is worth consideration for merging to the mainline
• No longer will people have to debate which is better, kdb or kgdb, why do we have only one... Just go use the best tool for the job.  :-)

What is the status of kgdboe and the mainline?

At the moment, no plans are in progress to merge kgdboe (KGDB over Ethernet) to the mainline kernel.

The current design where kgdboe relies entirely on the NET POLL API makes it unreliable. In a kernel with IRQ PREEMPTION turned on it is possible that Ethernet device cannot be shared safely between the polled and the interrupt driven context because a lock or structure may be taken when a driver is preempted and the kernel debugger is active.

If you are interested in solving problems related to kgdboe, please drop a mail to the kgdb mailing. There were several proposals to attempt to solve the problem design wise, but none have been implemented yet.

• Use the upcoming Ethernet queuing infrastructure to have a dedicated poll I/O space for kgdboe where it has its own MAC address.
• There was some work done by Intel for a reliable NET POLL interface using a dedicated queue on an E1000E based PCI device, but it was not completed
• Create plumbing to use the net device structure directly for exclusive access to an Ethernet device by only the kernel debugger.
• If you have something better for a design proposal we would love to hear about it! :-)