The kdb command

The kdb command can be used for analyzing the following:

• A running system.

  When used to analyze a running system, the kdb command opens the /dev/pmem special file, which allows direct access to the system's physical memory and bypasses the normal address translation mechanism of the processor. The kdb command performs its own address translation internally using the same algorithms as the KDB kernel debugger. This allows the user to view data by effective address.

  Note: Only the root user can use the kdb command to analyze a running system.
• A system dump file produced by a previously crashed-system.

  When a system crashes, the system dump image is created with memory translation turned on. As a result, any physical memory not mapped to the effective address space at the time of the dump cannot be included in the dump file. Only the memory belonging to the process that was running on the processor that created the dump image can be included in the dump file. Because all addresses within the system dump are already effective addresses, the kdb command does not perform its internal address translation.

  A system dump contains certain critical data structures. A system dump does not contain the entire effective address space. The kdb command might not be able to view certain memory regions. If someone attempts to access a memory address not included in the dump, the kdb command prints a warning message.

  When analyzing a system dump, it is imperative that the kdb command uses the same version of the UNIX file that was running at the time of the dump. To check the time stamps of dump and UNIX files, use the following commands:

  $ what unix | grep _kdb_buildinfo
           _kdb_buildinfo unix_64 Mar 14 2005 10:24:29 (This is the return that users will get.) 
  $ what dump | grep _kdb_buildinfo
           _kdb_buildinfo unix_64 Mar 14 2005 10:24:29

  The time stamps of both files must be identical. It is also possible to check the time stamp of the kdb command by running the following commands:

  $ what /usr/sbin/kdb_64 | grep _kdb_buildinfo
           _kdb_buildinfo unix_64 Mar  4 2005 14:45:20
  $ what /usr/sbin/kdb_mp | grep _kdb_buildinfo
           _kdb_buildinfo unix_mp Mar  4 2005 14:31:53

  This time stamp will typically be older than that of the dump and UNIX files. Usually, the kdb command can read the dump in this condition. However, if the version difference between the kdb command and the UNIX file is too large, kdb might be unable to read the dump. In this case, use a version of kdb that is closer to the UNIX version that is used.

  Note: The cdt subcommand or the -v command-line option can be used to determine exactly which regions of the effective address space are included in the system image. For more information about the CDT subcommand, see cdt subcommand. For more information about the -v command line option, see kdb command.

The kdb command contains a subset of the subcommands found in the KDB kernel debugger. Subcommands for setting breakpoints and single-stepping through code are not available in the kdb command. Because the kdb command is implemented as an ordinary user-space program, it has no control over the processors in a system. Similarly, any subcommands that directly access hardware (for example, the PCI subcommands) are not available. When you work with a system dump, any subcommands that modify memory are not valid because the system dump is merely a snapshot of the real memory in a system.

The complete list of subcommands available for the KDB kernel debugger and kdb command are included in Subcommand lists.