Filter
Top Products
– Remove any settings of the $kdebug_line variable as follows:
set $kdebug_line=
• Start dbx on the build system. You should see informational messages
on the terminal line /dev/ttyp2 that kdebug is starting.
• If you are using a gateway system, ensure that the inetd daemon is
running on the gateway system. Also, check the TCP/IP connection
between the build and gateway systems using one of the following
commands: rlogin, rsh,orrcp.
2.3.4 Notes on Using the kdebug Debugger
The following list contains information that can help you use the kdebug
debugger effectively:
• Breakpoint behavior on SMP systems
If you set breakpoints in code that is executed on an SMP system, the
breakpoints are handled serially. When a breakpoint is encountered on
a particular CPU, the state of all the other processors in the system
is saved and those processors spin. This behavior is similar to how
execution stops when a simple lock is obtained on a particular CPU.
Processing resumes on all processors when the breakpoint is dismissed;
for example, when you enter a step or cont command to the debugger.
• Reading instructions from disk
By default, the dbx debugger reads instructions from the remote kernel’s
memory. Reading instructions from memory allows the debugger to help
you examine self-modifying code, such as spl routines.
You can force the debugger to look at instructions in the on-disk copy of
the kernel by adding the following line to your $HOME/.dbxinit file:
set $readtextfile = 1
Setting the $readtextfile variable might improve the speed of the
debugger while it is reading instructions.
Be aware that the instructions the debugger reads from the on-disk copy
of the kernel might be made obsolete by self-modifying code. The on-disk
copy of the kernel does not contain any modifications made to the code
as it is running. Obsolete instructions that the debugger reads from the
on-disk copy can cause the kernel to fail in an unpredictable way.
2.4 The crashdc Utility
The crashdc utility collects critical data from operating system crash dump
files (vmzcore.n or vmcore.n) or from a running kernel. You can use the
data it collects to analyze the cause of a system crash. The crashdc utility
2–44 Kernel Debugging Utilities