How symmon Is Entered

How symmon Is Entered

When the system boots a debugging kernel with symmon installed, control can pass into the debug monitor under several different circumstances:

Early in the bootstrap process, if certain environment variables are set in the stand-alone shell (see "Entering symmon at Boot Time").
Whenever a control-A character is typed at the system console terminal.
Whenever a breakpoint is reached or a watchpoint is tripped (see "Commands to Control Execution Flow").
Whenever a kernel module calls the kernel function debug(uchar_t *msg).
When a non-maskable interrupt (NMI) is detected.
When a kernel panic is detected or forced with cmn_err().

When symmon gains control, it displays its "DBG:" prompt at the console terminal and waits for a command.

To resume execution at the point of interruption, enter the c (continue) command.

Using symmon in a Uniprocessor Workstation

In a single-processor workstation such as the Indy or Indigo2, no IRIX execution takes place while symmon is running. The mouse and keyboard are unresponsive. (One keystroke may be stored in the keyboard hardware to be processed when the system resumes execution.) As a result, time-dependent processes can fail; for example, the system clock is not updated. Network interrupts are not taken, so if the workstation is acting as an NFS server, it will appear to be dead to other systems.

Using symmon in a Multiprocessor Workstation

In a multiprocessor, the CPU that was interrupted runs symmon and nothing else. For example, the CPU that executes the breakpoint, or the CPU that handles the DUART interrupt that returns the control-A character, or the CPU in which debug() was called, comes under the control of symmon. Other CPUs continue to execute normally. However, if the symmon CPU holds a lock, other CPUs may come to a halt waiting for the lock to be released.

The symmon breakpoint table is shared by all CPUs. A breakpoint set from one CPU can be taken by another CPU, or by multiple other CPUs. It is possible to run multiple instances of symmon concurrently. The output from all instances of symmon is multiplexed onto the system console terminal. However, only one CPU at a time issues the DBG: prompt. Use the cpu command with no argument to find out which CPU is prompting. Use the cpu command with a cpu number to switch to a different CPU. (See "Commands to Control Execution Flow".)

Tip: To make multiprocessor execution more predictable, reduce the number of available CPUs. Use the PROM monitor to disable one or more CPUs before bootstrap.

Entering symmon at Boot Time

You can cause the kernel to stop during initialization and enter symmon during the bootstrap process. In order to do this, you must use the miniroot to set environment variables.

Restart the system, for example by giving the commands sync and halt. Eventually, the 5-item PROM menu is displayed at the console terminal.
Select item 5, "Enter the Command Monitor."
Set one or both of the environment variables dbgstop and symstop to 1, using commands such as the following:
>> setenv symstop 1
Return to the PROM menu by entering the command exit.
Select menu item 1, "Start System."

In either case, symmon seizes the system and displays its DBG: prompt at the system console during bootstrap. When the dbgstop variable is set, symmon takes control of the system very early in the bootstrap process. Symbolic names are not initialized at this point. However, breakpoints can be set and memory can be displayed using explicit addresses.

When the symstop variable is set, symmon takes control after symbols are defined, but before driver initialization is begun. At this stop, you can display memory and set breakpoints based on entry point names of your driver.