Home My Accounts | Newsletter | News Flash | Contact Us | Search

 

Issues/Circulation
Current Issue: May 2005
Other Issues
Applications
Gaussian Parallel Performance
Amber 8 on Redwood
Mimosa Upgrade to G03 End of June
Programming
PGI Versions on Mimosa
Compiling Programs on Redwood
The Intel Debugger
The -O Intel Compiler Option
Endian Formatting on Altix
Services
MCSR in the Classroom
PBS Tutorial
Systems & Resources
Redwood Upgrade to 192 CPUs
32 New Mimosa Nodes End of June
Checking Parallel Efficiency
The MCSR Parallel-O-Gram
The Intel Debugger

by Frank Mathew

Some compiling and debugging tips for C++/Fortran programming, specific to the Linux platform and Itanium 2 Processor (Redwood)

Assumptions:

1)      Although Redwood has multiple compilers, the compilers being used are version  8.0.0*

2)      The C++/FORTRAN compilers and other pertinent files are installed under: /opt/cmplrs/8.0.0*/

For example on Redwood:

The C++ compiler “icc” is under: /opt/cmplrs/8.0.066/bin

The FORTRAN compiler “ifort” is under: /opt/cmplrs/8.0.046/bin

3)      The Intel debugger being used “idb” is under: /opt/intel_idb_73/bin

Initialization:

Before we use the compiler or debugger, some relevant environment variables need to be set to specify the location of the different components. Scripts have been provided that do what is required.  We can either execute the script son the command prompt as shown below or put it in the start up script of the shell. See the MCSR Webpage on loading Intel compiler modules.

Compilers:

Here are some features and benefits of the Intel 8.* compiler:

1.      The Intel compiler is binary level and source level compatible with the GNU compiler. So this means that we can use libraries that were built using the GNU compiler in a program that is to be built by Intel by specifying the “-cxxlib-gcc” option.

2.      A significant performance gain can be gained by using optimizations. These optimizations can be made specific to the application being developed. There are quite a few optimization options that can be specified to the compiler. See the article on optimization tips in this issue.

3.      It supports shared memory parallel programming and larger application modules.

 

Debugger:

Besides the default ‘DBX’ mode, the Intel debugger also supports the GNU debugger. So when the ‘-gdb’ option is specified it is in the ‘GDB’ mode and behaves like the GNU debugger. When a bug is found in the program it is recommended that we make a reproducer of the bug which is simple so that the bug can be zeroed in on more easily. Once the bug reproducer is ready here are the steps to follow to find the bug:

  1. Initialization:
    1. Execute the debugger’s environment setup script.
    2. Set the terminal size information depending on terminal size, ex:

$ stty rows 25; setenv LINES 25

$ stty cols 80;  setenv COLS 80

    1. Compile and link your program using the ‘-g’ switch, Example if our bug reproducer is ‘test.c’: $ icc –g test.c
  1. Start-up the debugger: There are two basic methods by which we can invoke the debugger to debug the bug reproducer ‘test.c’, either create the process for the compiled and linked ‘test.out’ using the debugger or execute ‘test.out’ and attach the debugger to ‘test.out’ process by using its process id.
    1. Two further options for creating the process:

                                                               i.      Using the shell command line:

$ idb test.out

                                                             ii.      Using the debugger commands

$ idb

(idb) load teat.out

    1. Two further options for attaching the debugger to ‘test.out’ process.

                                                               i.      Using shell command line

$ idb test.out –pid ‘process_id_test.out’

                                                             ii.      Using debugger commands

$idb

(idb) attach ‘process_id_test.out’ test.out

  1. Stepping Through: Once the Intel debugger has started up the command prompt changes to “(idb)”. At this prompt we can type “help” to get a menu of available information for different features of the debugger. Also “quit” is used to quit the debugger and return to the shell.

Here is a list of different ways by which to step through the code of the bug reproducer “test.out” and set break points:

Setting break points:

    1. To stop when we enter a function. Ex: stopping in the “main” function, we first load the executable “test.out”, then instruct the debugger to stop when we reach main and finally run the code till the requested stopping point:

$idb test.out

(idb) stop in main

(idb) run

    1. Stop at a particular line using the line number. Ex. Stopping at line number 64 of the source code of “test.c”

$idb test.out

(idb) stop at 64

(run)

    1. Stop at a particular line in a different source file “test2.c”. Ex.

$idb file test2.c

(idb) stop at 64

    1. “status”: To see all the breakpoints that have been set use the command
    2. “cont”: Resume execution until a breakpoint occurs or until the program terminates normally or an exception occurs.
    3. “next”: Execute the next line of code, if the next line of code is a function call, the function call is executed and the debugger stops at the next line of executable code after the function call.
    4.  “step”: Execute next line of code, if the next line of code is a function call, the debugger steps into the function and stops at the first line of executable code in the function.
    5. “return”: continue execution of this function until it returns to its caller.
  1. Miscellaneous Debugger Commands: Besides the basic debugging commands above the debugger supports many other commands, the documentation for which is available using the “help” command. Here is a brief description of some of the other available commands:
    1. “list”: List the contents of the source file, it can take line number as argument, “>” in the output indicates the next instruction that the debugger can execute.
    2. “printregs”: To print the contents of the registers.

--------------------------------
Last Modified: Thursday, 19-May-2005 16:33:11 CDT
Copyright © 1997-2005 The Mississippi Center for Supercomputing Research. All Rights Reserved.
[an error occurred while processing this directive]