Launching the debugger

Although the debugger is called Xcdb, don't launch it by typing its name! The debugger needs to know the path of the source files that produced the binaries you are going to debug.

Instead of providing this long pathname as a command argument every time you start the debugger, put the path in a fetch path environment variable, and then use the TalDB script to parameterize the launching of Xcdb automatically:

In an xterm window, move to the source code directory:
Put the complete pathname into the TaligentFetchPath environment variable ; enclose pwd in grave--backquote--characters (`), not singl quotes ('):

Setting the fetch path

Rather than retype this setting every time you debug a program whose source code is located in a directory different from the current fetch path, create a UNIX alias named SetFP to do this for you. Then you need to run SetFP only when you want a different directory. To define SetFP, place the following line in your .cshrc (the env | grep stuff just echoes the new setting):

alias SetFp 'setenv TaligentFetchPath `pwd`; env | grep TaligentFetchPath'

To add directories to TaligentFetchPath once it exists, use this alias:

alias AddFp `setenv TaligentFetchPath "{TaligentFetchPath}:"`pwd`:"`pwd`'

When you begin more sophisticated multidirectory development, you will want to stop using SetFP and instead edit your .cshrc or .sh to set TaligentFetchPath to a colon-separated list of source directories.

From the same xterm window in which you set the fetch path, move to the shared library directory:

cd $TaligentSharedLibs

Launch the debugger from the shared library and specify the name of your application on the command line.
If your application is based on the Presentation framework, use RunDocument to specify the application:
For information about RunDocument, see
"RunDocument" on page 86.
For other applications, just specify the program's name:

The debugger has an unorthodox user interface that differs from both AIX windows and SNiFF+. Because of this, developers often don't learn to use the debugger or underestimate its capabilities. Make a point of reading Part 2, Chapter 11, "The Xcdb debugger" on page 115 and practice using the debugger for a while; you'll find that it is quite powerful. For example, you can modify the values of all locals and globals, list stack frames (even those of Taligent framework code), set conditional breakpoints, customize the way data is displayed, attach to any running process (to which you have access rights) at any point, and change the value of the this pointer.

[Contents] [Previous] [Next]

Click the icon to mail questions or corrections about this material to Taligent personnel.

Generated with WebMaker