Specifications

Driver Testing and Debugging

15-

the input and output. As soon as any one of these operations fails, you should reboot the

system immediately to ensure that kernel memory is sane.

Driver Debugging Techniques 15

This section describes the key facilities that are available to help you debug a driver. These

include the console processor, crash(1M), kdb(1), and cmn_err(D3). Use of these

facilities is explained in the sections that follow.

Using the Console Processor and Setting Breakpoints 15

The console processor (hereinafter referred to as CP) can be used to do breakpoint debug-

ging of the device driver. This section highlights only the CP features that are applicable to

debugging. For further information, see the HN6200 or HN6800 Console Reference Man-

ual.

In order to use the CP to debug, an assembler listing of the driver is needed (use the –S

option when invoking cc to compile the driver). Some skill is involved in mapping the

assembler code to the original C code; this develops with experience. In addition, the

virtual address of the beginning of the driver is needed. This address can be obtained by

running kdb against the kernel object file.

Note that the console processors have built–in symbolic capabilities. See the HN6200 or

HN6800 Console Reference Manual for details.

The normal procedure to use when setting breakpoints is as follows:

• The system is booted.

• The CP ~i or ~h command is used to halt all the CPUs. To use one of these

commands, type the following:

<carriage return>~i

<carriage return>~h

(Pressing the console wakeup button achieves the same result.)

• Breakpoints are set as desired using the CP b command.

• The CP r command is used to start the system running again.

• Test cases that execute the breakpointed instructions are run.

• When a breakpoint is hit, other CP commands are used to examine the reg-

isters and memory. Execution resumes with the r command.