Choosing the tool to use

Most developers use a combination of these tools in the course of debugging a driver. Depending on the problem, time, situation and personal preferences, you debug differently. Some considerations for which tool to use:

• Only the kernel debuggers allow you to write to the kernel to modify variables and to breakpoint or single-step through the kernel. Using standard C syntax, you can do what you want to within the executing kernel.

  The debuggers have few facilities to prevent programmer error. You can damage the integrity of the kernel with a debugger, whereas it is impossible to damage the kernel by running crash.

• crash is generally used to analyze a postmortem dump, although the SCO OpenServer 5 scodb can also be used for this purpose.

• kdb uses Reverse Polish Notation (RPN), also known as postfix notation, whereas scodb uses infix notation. For example, infix notation is ``3 + 4'', and postfix notation for the same operation is ``3 4 +''. So, to set a breakpoint on the foo function with kdb, the construct is:

     kdb>> foo 0x1f + b
  

• scodb maintains a command history whereas kdb does not. scodb supports vi-style command line editing on both platforms, although emacs-style command line editing is currently supported only on SCO OpenServer 5 systems.

• The debuggers are more effective for walking structures than is crash.

• On SVR5 systems, use kdb for all stack trace activities.

• When you switch between debuggers on SVR5 systems, you have to get out of the debugger and you lose some context.

• The crash output is formatted better than the output from the debuggers.

• crash is static, allowing you to look at the kernel at a particular moment.

• crash only allows you to view pre-defined structures whereas the debuggers allow you to look at all portions of the kernel address space. For SVR5 systems, crash is extensible, meaning you can define additional structures to be displayed by crash.

• crash sometimes fails as a debugging tool because it is difficult to freeze the core image at exactly the point where the error occurred; even if the error causes a system panic, the core image may be from beyond the point of actual error. This is especially true when debugging an intelligent board, because an autonomous intelligent controller continues processing even though you have halted kernel-level processing on the main memory. Moreover, for intelligent boards, the crash dump cannot get at the onboard data structures.

See the crash or crash(ADM) manual pages for more information about using the crash command. See ``Using SCODB on SVR5'' for more information about using the SVR5 scodb debugger, ``Using SCODB on SCO OpenServer 5'' for more information about using the SCO OpenServer 5 scodb debugger, and kdb for more information about using the kdb debugger. ``SCO kdb and scodb quick reference'' contains quick reference material for both debuggers.