CASEVision Debugger

CASEVision is an advanced debugging environment for SGI. It is currently available on both D0 challenges d0cha and d0chb and some other D0 SGI nodes, such as d0sgib, d0sgic, etc.

Starting and Exiting the Debugger

Before you start the debugger, make sure your environment variable $DISPLAY has been correctly set by doing echo $DISPLAY. If not, in csh/tcsh, do:

setenv DISPLAY your-graphical-terminal:0.0

To start the Debugger, you use the following syntax:

cvd [-pid pid] [executable | corefile] [&]

The -pid option lets you attach the Debugger to a running proce. You can use this to determine why a live process is in a loop.

The argument executable is the name of the executable file for the process you want to run. It is optional; you can invoke the Debugger first and specify the executable later.

You can also invoke the Debugger and specify a core file (with its executable) to try to determine why a program crashed.

After you invoke the debugger, there will be two windows poped up, one is Execution View, another one is the Main View with "WorkShop Debugger" caption. The Execuation View window is for the input/output of an executable, just like a shell.

To exit the Debugger, select "Exit" from the Admin menu in the Main View window. You have two other options: you can type quit at the Debugger command line or press <ctrl-c> where you first entered cvd.

Using Main View

Starting the Debugger with an executable brings up the Main View window, loaded with the source code, and ready to run the process with any specified arguments. You perform most of your work in Main View , which provides:

a menu bar for performing Main View functions and for accessing other views
[ Admin Views Query Source Display Data Traps PC Fix+Continue Help ]
a control panel for specifying and controlling the process to be debugged
[ Continue Stop "Step Into" "Step Over" Return Sample Print Kill Run ]
Click those buttons will let you control the debugging processing.
a status line for viewing the state of the program
a source code display area for inspecting the source code
the Debugger command line for entering special debugging commands
[ Area with prompt cvd> ]

Setting Traps

A major part of the debugging process is inspecting data at points during execution. A trap is a mechanism for gathering this data. A stop trap halts the process so that you can manually examine data. A sample trap collects specified performance data without stopping.

The Debugger lets you set traps:

at a line in a file (breakpoint)
[ Click left mouse key between the left border and source code display area,
Click again to cancel the breakpoint. ]
on entry to or exit from a function
[ type "stop in function_name" at the Command line ]
at an instruction address
when a signal is received
when a system call is made, at either the entry or exit point
when a given variable or address is written to, read from, or executed (watchpoint)
at set time intervals (pollpoint)

Inspecting Debugger Data

When you stop the process, you then have a number of options for examining the data. You can inspect:

the call stack at the breakpoint (using Call Stack under Views menu )
the value of specified expressions (using Expression View under Views menu )
the values, types, or addresses of variables (using Variable Browser)
data structures (using Structure Browser)
the values of an array variable (using Array Browser)
values in specified memory locations (using Memory View ) or registers (using Register View)
the disassembled code (using Disassembly View)

Changing Source Code

To change your source code and recompile, follow these steps:

Switch to a text editor by clicking Fork Editor selection in Source menu or clicking Make Editable in Source menu) then edit directly in the source.
Make any changes and save them by selecting Save... from the Source menu.
Select Recompile from the Source menu.

The Build View window displays and lets you start the compile. Any compile errors are listed in the window, and you can access the related source code by clicking the errors.

When the code is rebuilt successfully, the new executable reattaches automatically to the Debugger and Static Analyzer. Previously set traps will be intact unless you have traps triggered at line numbers and have changed the line count.

Integration with Other WorkShop Tools

The WorkShop tools are designed so that you can move easily between them in a work session.

Accessing the Performance Analyzer from Main View
You can switch to the Performance Analyzer at any time while debugging. Selecting Performance Task... from the Admin menu lets you enable data collection for your experiment. A performance task must be specified before the process is run; this enables the correct data collection. If you are in the middle of a run, you must terminate it, select a task, and restart the target to collect the data. Selecting Performance Analyzer from the Launch Tool submenu displays the main Performance Analyzer for analyzing the experiment results.
Accessing the Static Analyzer From Main View
You can access the Static Analyzer from the Launch Tool submenu, if desired. The Static Analyzer displays source information from Main View, making it easy to set traps in source code located by the Static Analyzer. Note that the Query menu enables you to conduct some of the same queries as in the Static Analyzer.

Last Updated May 30, 1997 by Dong Zhao