 |
Software Interest Group
The UA Math Department Software Interest Group (SWIG)
is a self-organized informal group, consisting of faculty members,
visitors, staff, and graduate students, whose goal is to promote and
advance computer and software literacy among the members of the department
through meetings, talks, and discussions.
|
 |
For more details, and talks in past semesters, consult the full schedule of talks.
Past topics can (and should) be repeated occasionally. In addition, here are some topics people might like to hear about:
To give a talk, please contact swig@math.arizona.edu.
There are two other versions of dbx that make running it much easier: xdbx, an X windows version; and dbxtool, an OpenWindows version. Both of these have similar functionality and layout, so we will only review xdbx, which seems more popular. The instructions will be nearly identical for using dbxtool. Both xdbx and dbxtool have man pages, as does dbx.
Another debugger available is gdb, a GNU product. It is not windows based, so it doesn't have quite the ease of use as xdbx and dbxtool, but it can be run under emacs.
For the purposes of this talk we will discuss xdbx and gdb.
The debuggers can read programs written in C, C++, Fortran, Pascal, or Modula-2. First, your program must compile successfully. Second, any program or parts of a program that are to be debugged must be compiled with the -g option, which creates a set of tables for the debugger to interpret. This option makes the program run slower and negates any optimization flags like -O or -cg89, so you should remove the -g flag once your code is fully debugged. Also, although the main program must be compiled with -g, any subroutines that are fully debugged do not; so if your program calls subroutines in another file, once they are fully debugged you can compile those subroutines with any optimization.
To use xdbx, at the Unix prompt type
xdbx prog
where prog is the name of the executable file. A
window pops up that has three main parts: the source code in
the top half, the command window in the middle, and the
dialogue window in the bottom. Clicking the left mouse button
on in the source window will position a caret at that point,
which is useful for setting or deleting breakpoints. Clicking
twice will highlight the nearest variable or function name,
useful for displaying values of variables or skipping to a
function.
Any dbx command can be entered at the prompt in the dialogue window, but most of the commonly used commands have buttons in the command window, so below is a description of each button. Each is activated with a clicking the left mouse button on the appropriate command button.
Here is a list of useful commands/buttons:
run
stop at
stop in
delete
status
cont
next
step
print
print*
display
undisplay
dump
search
where
up,down
func
file
Some of these can be entered on the command line and given
additional arguments. For example, typing next
50 will execute the next 50 lines, which is useful for
jumping over a section of the program. Also, conditionals can
be given, such as stop if i==300, which stops
the program if i=300. Other useful commands include:
trace
edit
make
sh
help
For those programming in C, print has a nice (though
primitive) tool for showing pointers and structures: if one
is highlighted, click on print with the right
mouse button and its value will be displayed in a popup
window. If the value is a pointer, clicking on its value will
create another popup showing the object at that address.
These popups are removed by clicking on their labels.
Unfortunately, this does not allow you to increment the address to see other values. This is a problem if you habitually dynamically allocate your arrays. One fix for this is to statically allocate the array while debugging, then switch to dynamic allocation.
M-x gdb. You will be prompted for the name of
your execulable -- enter it and hit return. The debugging
symbol table will be loaded in and the gdb prompt "(gdb)" will
apprear. Now you're ready to go!
With gdb one can get a source window and a dialogue window so that one can step through the execution of the program line by line and see what is happeneing. The screen will not split until the program runs, so it helps to put a break point early in the code to get the split screen.
Some handy commands:
help
file progname
run progname arg1 arg2 ...
list m, n
break n
step
next
display varname
continue
info breakpoint
For xdbx users, gdb has some differences. For example, since
gdb is not a version of dbx, some of the commands are
different. Most notably, the command for setting a breakpoint
at line 17, say, is break 17. Some commands have
abbreviations, such as n for next,
s for step, and c for
cont.
The advantages of gdb are that it is free and that it can run on a wide variety of machines (SUN, Linux, etc.). Also, the fact that it can run under emacs makes it more attractive than dbx if you cannot run window applications.
