KDB kernel debugger
Although it must be manually enabled by the user prior to use, the KDB kernel debugger is statically compiled into the AIX kernel and is always loaded. After it is enabled, the KDB kernel debugger can be manually invoked by the user or automatically invoked by the system in response to some condition (for example, an unhandled exception in the kernel code).
KDB kernel debugger is always loaded into a special region of pinned memory where the effective address space equals the real address space. The KDB kernel debugger runs with memory translation turned off. This allows it to function even if the VMM subsystem is not yet initialized or the critical VMM structures are corrupted. However, the KDB kernel debugger can perform the same address translations normally performed by the processor. This allows the user to view data by effective addresses when the processor has its memory translation turned off.
When the KDB kernel debugger is invoked by a condition, it is the only running program. All other processes are stopped and processor interrupts are disabled. One of the processors is designated as the debug processor and that processor runs the KDB kernel debugger. This is usually the processor on which an unusual activity occurred (for example, an unhandled exception).
If the KDB kernel debugger is invoked manually by the user, the debug processor is arbitrarily chosen. The KDB kernel debugger stops all other processors in the system by sending an interprocessor interrupt (IPI) to each processor. If any of these processors cannot be stopped, the KDB kernel debugger prints a warning message. For example, if a processor is spinning on a lock with interrupts disabled, it cannot process the IPI sent by the KDB kernel debugger.
The KDB kernel debugger is mostly self-contained and does not rely on other kernel components such as the network and video drivers. The KDB kernel debugger runs with its own Machine State Save Area (mst) and a special stack. This requires that some kernel code be duplicated within KDB kernel debugger. Duplication allows the developer to debug from almost anywhere within the kernel code. Unless the KDB kernel debugger is entered through a system halt, processors resume normal operation and interrupts are re-enabled when the developer exits the KDB kernel debugger.
When it is invoked, the KDB kernel debugger takes control of either the virtual terminal (vterm) on a logical partitioning system, or a physical RS232 serial port on a non-logical partitioning system. This requires a Hardware Management Console (HMC) to access the vterm or another system connected to the serial port on the system being debugged. The KDB kernel debugger requires the connection in order to send messages to the developer.
The complete list of subcommands available for the KDB kernel debugger and kdb command are included in Subcommand lists.