Debugging Tools Techniques Tips – Debuggers

Platform (In)Dependence

Most of these tools are only available on a single platform. However, please do not feel constrained to only use the tools on the platform you are targeting. Since many machines have a similar architecture, i.e. cache-based, RISC, microprocessors, where the performance is strongly dependent on the cache utilization, you will no doubt find that code improvements made on one architecture result in performance gains on other architectures as well. Similarly when debugging, it is usually the case that a bug is a bug. You can find it on one machine so that it will be fixed for all machines.

Time Expectations

New tools are great! They enable you to do new things and make you more efficient. But what’s the learning curve? How much time do I need to invest before this tool makes my life better? For the debuggers the answer is – immediately. These are all simple to use and fairly self-explanatory. You should immediately be able to run code, set breakpoints, query variables, etc. Obviously, the more you use, them the more tricks and treats you’ll find. For the performance tools, the answer is a bit tougher. If you are already familiar with performance issues then you will be able to use the tools with very little startup time. However, if you are new to performance tuning then you will need to invest some time in going through the tutorials and studying performance issues online.

Common Features of all Debuggers

Debuggers are useful for finding problems in your code. They allow you to view your source, run your code, control code execution, set breakpoints, query variables, examine core files, and many, many other functions as well. It is usually much more efficient (and simpler!) to use a debugger rather than sticking a bunch of print statements in your code. While there are a lot of debuggers available (see list below) once you learn how to use one it is easy to swich to another since the basic functionality provided is the same. It’s much like driving a new car. You may not know where to turn on the lights or the windshield wipers when you first step in, but you know it’s there somewhere. Still, the Rolls Royce of debuggers is the totalview debugger from Etnus. This provides the richest set of functionality, is simple to use and is clearly the most superier for debugging parallel code. Thus, it is our recommendation for compiler of choice however any of the compilers below will prove useful to you in a pinch. Here are some common things to keep in mind when using any of these debuggers.

1. Compile your code with the -g option. This gives the debugger access to the symbol table information and allows you to see your source.

2. Optimizations may move code segments around. You can debug optimized code but if you are confused in steppng through the code, you may want to turn off all optimizations.

Some compilers will do this automatically when you use -g.

3. Typically you run the debugger from the directory where your source and executable are. Optionally you may have your source in a different directory but you will then need to tell the debugger where it is.

4. Start it up, in general:

debugger_name my_executableFor example:

totalview a.outcvd

The WorkShop Debugger, which is a source-level debugging tool that provides window interface (views) for displaying program data and execution status. The WorkShop Debugger lets you set various types of breakpoints, watchpoints, and other types of signals. You can also view variables, expressions, structures, arrays, call stacks, and machine-level values. You can use the debugger to debug Ada, C, C++, Fortran 77, and Fortran 90 programs.

Machine Name	Cedar/Cypress

For more information, use the manual at:

man cvdYou can also see the “ProDev WorkShop: Debugger User’s Guide”. Search for the guide in the SGI Tech Pubs library using cvd as the keyword.

dbx, gdb, pdbx

These are mostly command line debuggers (i.e. no nice GUI or data displays). They provide all of the standard debugging functionality such as controlling program execution, monitoring memory locations, and tracing problems. dbx (and variants) is the BSD unix debugger, gdb is the GNU debugger, and pdbx is a parallel version of dbx from IBM.

Debugger	Machine Name
dbx	Yatta on Emerald
gdb	Emerald, Cedar/Cypress
pdbx	Yatta on Emerald

For more information, use manuals at:

man dbxman gdbman pdbxpgdbg, idb, fx(xfx) These are the debuggers from each of the compiler vendors installed on the Linux cluster.

Machine Name: Emerald

We make no gurantees that that code compiled with one vendor’s compiler can be analyzed with another vendor’s debugger.

Vendor	Debugger	Package
Portland Group	pgdbg	pgi
Intel	idb	intel_fortran, intel_CC
Absoft	fx (xfx for the gui version)	profortran

ipm add the desired vendor, either profortran, pgi, or intel_fortran and intel_CC, for Absoft, The Portland Group and Intel, respectively.

For more information, use manuals at:

man pgdbgman idbFor more information about fx debugger, run the GUI version of fx and then click on help.

totalview

Etnus TotalView is the most advanced debugger available on Linux and UNIX. It helps eliminate the frustration, delays, and pain inherent in developing complex applications, such as those that require massive amounts of data, have many lines of code or empty threads, and other forms of parallelism. It provides support for C/C++, compilers, and the platforms you use every day. TotalView also gives you memory tracking, support for Standard Template Libraries, and a host of other features absent in run-of-the-mill debuggers in order to help you find even the most elusive bugs fast. TotalView is for developers who require a premium tool, a debugger that really works.

Machine Name: Emerald

To use this debugger, you need to add it to your working environment.

ipm add totalview

SpeedShop

The SpeedShop tools allow you to run experiments and generate reports that determine the sources of performance problems and indicate areas in your code where application performance can be enhanced.

Machine Name:
Cedar/Cypress, Yatta on Emerald

To run the SpeedShop experiment pcsamp which estimates program time, try

ssrun -pcsamp my_executable prof my_executable .pcsamp.mxxxxx my_report

That is, you run your code with ssrun and it will create an output file with the experiment type and a process number appended to it. You then analyze this file with the prof command. Prof outputs to stdout. You can also use cvperf to do the analysis with a GUI.

For more information, use manuals at:

man intro_ssman speedshopman profman cvperfYou can also see the “SpeedShop User’s Guide”. Search for it in the SGI Tech Pubs library using speedshop as the keyword.

Original Post – http://help.unc.edu/6330

Related Posts:

• No Related Posts

Tags: Application Debugging Tools

You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.