Intel® Debugger for Linux* Release Notes

Intel® Debugger (idb) for Linux*, for versions:

To receive technical support and updates, you need to register your Intel Software Product. See the Technical Support section.

A fully symbolic debugger for the Linux platform. Key features allow you to:

• Perform source-level debugging
• Attach to a running process
• Debug programs with shared libraries
• Work in a DBX- or GDB-like user interface
  

The debugger supports the debugging of programs written in C, C++, Fortran, and Fortran 90. The debugger allows evaluation of expressions using the syntax of the source programming language.

For full information about the debugger, please refer to the following manual:

Intel® Debugger Manual

which is found in the installation directory where these release notes reside.

Optional DBX- or GDB-like user interface
Graphical User Interface (GUI)
Debugging massively parallel processing (MPP) applications
Starting the debugger under Emacs
Debugging OpenMP* applications

Optional DBX- or GDB-like user interface

Users can switch to the DBX- or GDB-like interface, depending on their preference. In Compiler version 9.1 and older, the default interface is DBX. In Compiler version 10.0 Beta and newer, the default interface is GDB (when running "idb" from the installed location), except in the GUI (where the default is DBX). The DBX and GDB command set (and debugger output) are supported as described in the manual.

To activate GDB mode, use the -gdb command line option (if it is not the default), or set the debugger variable $cmdset to gdb after starting the debugger, e.g.:

(idb) set $cmdset="gdb"

To activate DBX mode, use the -dbx command line option (if it is not the default), or set the debugger variable $cmdset to dbx after starting the debugger, e.g.:

(idb) set $cmdset="dbx"

Graphical User Interface (GUI)

A GUI is now available. Just use the -gui flag when invoking the debugger from the Linux command line.

Only the DBX-like interface is available from within the GUI.

Debugging massively parallel processing (MPP) applications

Debugging MPI applications compiled with mpich or Intel MPI 3.0 is supported to the extent described in the manual (Section Debugging Parallel Applications).

Starting the debugger under Emacs

The manual describes how to start the debugger in default mode under Emacs. To start the debugger in GDB mode under Emacs, do the following.

1. Select "Debugger..." under the Emacs "Tools" menu.
2. At the "Run gdb (like this): " prompt, type idb -gdb -fullname

To use the GDB-like interface, do not load the idb.el file documented in the manual.

Debugging OpenMP applications

When debugging an OpenMP* application, the debugger is capable of providing useful information on OpenMP locks, teams, and threads.

All compiler versions:

Compiler Version 9.1:

Compiler Version 10.0:

Enhanced MPI Support

The debugger is now capable of debugging a fresh MPI job that uses the MPICH or the Intel MPI 3.0 libraries. In addition, it is capable of attaching to an existing MPI job that uses MPICH.

Before you start debugging a MPI job with the debugger, make sure you have the environment variable IDB_HOME set to the directory where the debugger is installed.

To start a fresh MPI job under the debugger's control, do the following:

• If you use MPICH

  % mpirun -dbg=idb -np <number of processes> [other MPICH options ] <executable> [arguments to the executable]
  	  

  Note that you need to copy the script mpirun_dbg.idb that comes with the debugger's package to the bin directory of you MPICH installation.



• If you use Intel MPI 3.0

  % mpiexec -idb -n <number of processes> [other Intel MPI options ] <executable> [arguments to the executable]
  	  

To attach to an existing MPICH job, do this:

        % idb -pid <launcher pid> -parallelattach <executable >
	

The <launcher pid> is the ID of the launcher process that spawned all the processes in the job. You can use the Linux command "ps -xf" to find the ID of this process. The <executable> is the name of the launcher executable.

See Known Limitations for a list of issues with MPI support.

See Chapter 19 of the manual for further information on this support.

Enhanced GDB compatibility

These release features more GDB compatibility features. Included are the following features:

• Better DDD compatibility
• Support for initialization files
• Support for command history
• More GDB command line options
• Support for info variables, info types and info functions
• Command, filename and variable completion
• Support for user-defined commands

Better DDD Compatibility

Several bugs have been fixed in IDB's support for DDD. To use DDD, users should use this command:
ddd --debugger "idb -gdb"

Initialization files

Initialization files are supported in both DBX mode and GDB mode.

DBX mode behavior
Before attaching to or starting a target executable and before processing command line qualifiers, the debugger reads .idbrc in the current directory and executes it. If there is no .idbrc in the current directory, the debugger tries to read it from the user's home directory. If the -i option is passed, defining another initialization file, then it will be used instead of .idbrc.

After the target process has been loaded or attached to, and after processing command line qualifiers, the debugger reads .dbxinit in the current directory and executes it. If there is no .dbxinit in the current directory, the debugger tries to read it from the user's home directory. If the option -c is passed, defining another initialization file, then it will be used instead of .dbxinit.

GDB mode behavior
Before attaching to or starting a target executable the debugger reads .gdbinit in the user's home directory. After attaching to, or loading the target executable, the debugger reads .gdbinit in the current working directory. If the user's current working directory is the same as the user's home directory, then .gdbinit is read before attaching to or starting the target exeutable.

The debugger will read any command files specified by the -x option in addition to .gdbinit. Additionally, it will read the command history recorded in the history file (which defaults to ./.gdb_history)

There are several options for managing initialization files:

1. idb -gdb -x <command file>
   
   This is similar to -c and -i in DBX mode (remember that -i replaces .idbrc, -c replaces .dbxinit). This option however, processes command files passed with -x in addition to .gdbinit. -x can be passed to the debugger more than one time on the command line.
   
   
2. idb -gdb -n[x]
   
   -n and -nx cause the debugger to skip reading .gdbinit. However, if command files are also passed using -x, they are read and executed.

Command History

The In GDB mode, the debugger will read .gdb_history by default. You can also use the following commands to control the behavior of command history:

• Renaming the history file
  
  There are 2 ways to rename the history file, which will override the default (.gdb_history).
  1. (idb) set history filename <name>
     
  2. Set the environment variable GDBHISTFILE to the filename of the history file you want to use. This can be overridden during the debug session by using the set history file <name> command.
• Turning history recording on & off
  
  (idb) set history save [on|off]
  


• Configuring the history size
  
  There are 2 ways to configure the size of the history buffer (the number of items retained):
  1. (idb) set history size <number>
     
  2. Set the environment variable HISTSIZE to the size you want.
  
  If neither of these choices are used, the default value is 256.

GDB command line options

The following command line options are now supported:

--args

idb [-gdb] [idb options] [-]-args <exec_file [args for exec_file]

The first argument after this option must be an executable file. Arguments follow the executable file are command line arguments to the executable. When --args is encountered, remaining arguments are treated as if they should be sent to the executable. The executable file passed before encountering --args is ignored. After the debugger loads the executable, you can use show args to see all arguments that will be passed to the executable.

This option is available in both GDB and DBX mode.

--batch

idb [-gdb] [idb options] [-]-batch [-x <command file> ...]

Run the debugger in batch mode. The debugger will exit with a status of 0 after processing the initialization files and any command files specified with -x (assuming -n is not passed. ). If an error occurs in executing commands from command files or initialization files, the debugger will exit with a nonzero status.

This option is available in both GDB and DBX mode.

--core

idb -gdb -[-]c[ore][=|<space>]<core_file>

Debug a core file. You don't need to tell the debugger the name of the executable. The meaning of -c differs in DBX and GDB mode. In DBX mode it is used to pass a command file. You can combine the two meanings in the following way:


idb -c <command_file > -gdb -c <core_file>

--exec

idb -gdb -[-]e[xec][=|<space>]<exec_file>

Specify the executable to debug.

--pid

idb [-gdb] -[-]p[id] <process-id>

Attach to process, given the process-id. There is no need to specify the executable or core file.

This option is available in both GDB and DBX mode.

info variables, info types, info functions

info var[iables] [<string>|REGEXP]

<string> is a simple search string; REGEXP is a regular expression. The resulting list is the list of global and static variables in the debuggee that match <string> or REGEXP.

info fu[nctions] [<string>|REGEXP]

<string> is a simple search string; REGEXP is a regular expression. The resulting list is the list of global and static functions in the debuggee that match <string> or REGEXP.

info ty[pes] [<string>|REGEXP]

<string> is a simple search string; REGEXP is a regular expression. The resulting list is the list of types used in the debuggee that matches <string> or REGEXP.

Command, filename and variable completion

Completion of commands, filenames, and variables is supported. Simply start typing a command, filename or variable and press the tab key. If there is more than one alternative, the debugger sounds a bell; pressing tab again causes the debuger to list the alternatives.

Using single and double quotes influences the set of possible alternatives. Single quotes can be used to fill in C++ names, which contains special symbols (":", "<", ">", "(", etc.). Double quotas tell the debugger to look for alternatives among file names only.

The debugger doesn't automatically detect cases where quotes are needed (as GDB does).

Support for user-defined commands

The debugger now supports user defined commands. These commands support if, while, loop_break and loop_continue in their bodies. User-defined commands can have up to 10 arguments separated by whitespace. Argument names are $arg0, $arg1, $arg2,..., $arg9. The number of arguments is held in $argc.

The debugger supports the following commands to control user-defined commands:

• (idb) set max-user-call-depth <depth>
  Sets max level of recursion for user defined commands. The default value is 1024.
  
  
• (idb) show max-user-call-depth
  Shows current available level of recursion.

The debugger doesn't yet support the document, help user-defined, dont-repeat commands or user-defined hooks.

Support for Pending Breakpoints

If the user tries to set a breakpoint which cannot be resolved to as specific location, the debugger ask the user whether to create a special breakpoint, called a pending breakpoint. This breakpoint will be evaluated when shared libraries are loaded and if they can be resolved, that are transformed into a regular breakpoint (where the debugger can stop). The debugger supports specific commands for managing the pending breakpoint support:

• (idb) set breakpoint pending auto
  This is the default value. If the debugger cannot resolve breakpoint location, the user is asked whether to create a pending breakpoint.
  
  
• (idb) set breakpoint pending on
  Always set pending breakpoints on unresolved locations.
  
  
• (idb) set breakpoint pending off
  Never set pending breakpoint on unresolved locations.
  
  
• (idb) show breakpoint pending
  Show the behavior of the pending breakpoint support.
  
  

Normal breakpoint operations are valid for pending breakpoints. Pending breakpoints can be enabled, disabled and deleted. A user condition can be assigned to pending breakpoint and it will be promoted to the breakpoint when the location is resolved.

This feature is supported in DBX and GDB user interfaces.

OpenMP Support

The debugger is capable of providing information on OpenMP locks, teams, and threads when debugging an OpenMP application.

To enable this support, the debugger requires access to the shared library libomp_db.so, which by default is in the lib directory in your compiler installation.

The debugger automatically enables the OpenMP support when it detects that the debuggee is an OpenMP program. To switch off the support, do

(idb) set $threadlevel="native"

To switch it back on, do

(idb) set $threadlevel="openmp"

When the OpenMP support is on, you can use the following commands to inspect the states of the OpenMP objects in your program:

1. show lock [lock id, ... ]

   This command displays the state of the locks that are specified, or the state of all the locks if none is specified. E.g.:

   
   	(idb) show lock nlk
   	Id                  Type    State   Holder Id     Level     Waiters
   	0x6000000000009e00  nested  held    1             1         3 threads: 2, 3, 4
   
   		

   In this example, the lock nlk is a nested lock that's being held by Thread 1, which has set it only once (i.e., the Level). Three threads are waiting for it, Threads 2, 3, and 4. Note that the thread IDs used here (and all the following commands) are the debugger's thread IDs. In other words, you can use these IDs in a debugger command that takes a thread ID, such as "show thread".

2. show openmp thread tree

   This command displays the threads in the process in a tree format to illustrate the team master/member relation between threads. E.g.:

   
   	(idb) show openmp thread tree
   	Team 6917529027641117440
   	`--[0] Thread 1
   	   #--Team 6917529027641120768
   	      |--[0] Thread 1
   	      |  #--Team 6917529027641153024
   	      |     |--[0] Thread 1
   	      |     |--[1] Thread 5
   	      |     `--[2] Thread 4
   	      `--[1] Thread 3
   	         #--Team 6917529027641184768
   	            |--[0] Thread 3
   	            |--[1] Thread 7
   	            `--[2] Thread 6
   		

   The numbers in square brackets are the OpenMP thread IDs in their respective team.

3. show team [team id, ...]

   This command displays the information of the OpenMP teams that are specified, or that of all the teams if none is specified. E.g.:

   
   	(idb) show team 6917529027641120768
   	OpenMP Team:  6917529027641120768
   	Parent Team:  6917529027641117440
   	Created At:   "/projects/OpenMP/src/c_omp.c":main:58:98
   	Team members
   	  [0] Thread 1, is master of team 6917529027641153024
   	  [1] Thread 3, is master of team 6917529027641184768
   		

4. show thread [thread id, ...]

   This command displays the information of the threads that are specified, or that of all the threads if none is specified. E.g.:

   
   	(idb) show thread 3
   	   3     openmp thread 2305843009228110032 (LWP 13080)
   	         stopped at 0x2000000000866922
   	         OpenMP team memberships: (6917529027641184768,0), (6917529027641120768,1)
   		

   The ID in front of LWP is the thread ID assigned by the pthread library.
   The first component of a pair in the OpenMP team memberships is a team ID, and the second compoenent is the OpenMP thread ID in that team. These pairs are listed from the innermost team membership to the outer ones.

The first three commands are also available in GDB mode. To inspect a thread in GDB mode, use the "info thread" command.

Another feature that is available when debugging an OpenMP application is stack stitching. Here is a typical backtrace of an OpenMP thread:

	(idb) where thread 1
	Stack trace for thread 1
	>0 0x0000000000400cb8 in thread_func(param=0) "c_omp.c":14
	#1 0x0000000000400dc4 in main() "c_omp.c":23
	#2 0x0000002a95595d43 in __kmp_invoke_microtask(...) in libguide.so
	#3 0x0000002a9559e572 in __kmpc_invoke_task_func(...) in libguide.so
	#4 0x0000002a9559e75d in __kmp_internal_fork(...) in libguide.so
	#5 0x0000002a955982fa in __kmp_fork_call(...) in libguide.so
	#6 0x0000002a955a09f2 in __kmpc_fork_call(...) in libguide.so
	#7 0x0000000000400d94 in main() "c_omp.c":21
	#8 0x0000003cad01c4ca in __libc_start_main(...) in /lib64/tls/libc-2.3.4.so
	#9 0x0000000000400b40 in _start(...) in c_omp
	

In this backtrace, the frames in boldface correspond to functions in the OpenMP runtime library, which most users don't care about and only make the backtrace less comprehensible. Stack stitching removes those OpenMP runtime frames and put the remaining frames back together into a backtrace that maps cleanly to the user's source code:

	(idb) where thread 1
	Stack trace for thread 1
	>0 0x0000000000400cb8 in thread_func(param=0) "c_omp.c":14
	#1 0x0000000000400dc4 in main() "c_omp.c":23
	#2 0x0000000000400d94 in main() "c_omp.c":21
	#3 0x0000003cad01c4ca in __libc_start_main(...) in /lib64/tls/libc-2.3.4.so
	#4 0x0000000000400b40 in _start(...) in c_omp
	

When an OpenMP thread is a non-master member thread of a team, the stitched backtrace would show you the backtrace of the master thread starting with the frame that spawns the team:

	(idb) where
	>0  0x08048cf2 in foo() "src/c_stack_stitching.c":9
	#1  0x08049162 in main() "src/c_stack_stitching.c":35
	======== Frames from Team 134587904 master Thread 3 ========
	#7  0x08049139 in main() "src/c_stack_stitching.c":33
	======== Frames from Team 134548736 master Thread 1 ========
	#7  0x08048fdc in main() "src/c_stack_stitching.c":22
	#8  0x08048ef4 in main() "src/c_stack_stitching.c":18
	#9  0x08048e0c in main() "src/c_stack_stitching.c":15
	#10 0xb7380748 in __libc_start_main(...) in /lib/tls/libc-2.3.2.so
	#11 0x08048b01 in _start(...) in c_stack_stitching
	

When $threadlevel is set to "openmp", the value of the debugger variable $openmpstackstitching determines whether stack stitching is enabled: If its value is 0, stack stitching is disabled; otherwise, it is enabled. $openmpstackstitching is set to 1 by default. When $threadlevel is set to "native", stack stitching is disabled, regardless of the value of $openmpstackstitching.

See Known Limitations for a list of issues with OpenMP support.

Eclipse* Support

The Intel C++ Compiler for Linux* includes a debugger integration with Eclipse* and the C/C++ Development Tools* (CDT). This functionality is part of the debugger installation for IA-32 and Itanium® processors.

Eclipse is an open source software development project dedicated to providing a robust, full-featured, commercial-quality, industry platform for the development of highly integrated tools. It is an extensible, open source integrated development environment (IDE).

The CDT (C/C++ Development Tools) project is dedicated to providing a fully functional C/C++ IDE for the Eclipse platform. CDT is layered on Eclipse and provides a C/C++ development environment perspective.

The Intel Debugger integration with the Eclipse/CDT IDE lets you debug your C/C++ projects in a visual, interactive environment.

Intel C++ Compiler 9.1 includes integration for

• Eclipse* 3.1 and 3.1.1
• C/C++ Development Tools* (CDT) 3.0 & 3.0.1

Intel C++ Compiler 10.0 includes integration for

• Eclipse* 3.2.1
• C/C++ Development Tools* (CDT) 3.1.1

Intel C++ Compiler 10.1 includes integration for

• Eclipse* 3.3
• C/C++ Development Tools* (CDT)4.0

The Eclipse (IDB) plug-in version 4.0.0 is now available. This version is backward compatible to the older Eclipse* and CDT versions listed above.

Full details can be found in the

which is found in the installation directory where these release notes reside.

See http://www.eclipse.org for Eclipse Support.
See http://www.eclipse.org/cdt for further information about CDT.

Intel® Cluster OpenMP Support

The debugger is now capable of debugging an Intel® Cluster OpenMP application, bringing all the processes in a cluster OpenMP job under the debugger's control, and allowing the user to control all the processes in the job conveniently from one debugger.

To enable this support, the debugger requires access to the shared library libomp_db.so, which by default is in the lib directory in your compiler installation.

Before you start debugging a cluster OpenMP job with the debugger, make sure you have the environment variable IDB_HOME set to the directory where the debugger is installed.

To start a fresh cluster OpenMP job under the debugger's control, do the following:

	% $IDB_HOME/idb -clomp <executable> [arguments to the executable]
	

To attach to an existing cluster OpenMP job, do this:

	% $IDB_HOME/idb -pid <pid> -clomp <executable> [arguments to the executable]	
	

where <pid> can be the process-id of any process in the job.

This support uses the same debugger network infrastructure as the MPI debugging support. When debugging a cluster OpenMP job, the debugger provides a "stop the world" event handling model and an "all processes run" process control model. The "stop the world" model stipulates that when a process in the job raises an event, such as a breakpoint hit, the debugger would stop all the processes in the job and issues the user prompt. The "all processes run" model stipulates that when the user issues a mover command (such as "cont" or "next"), all the processes in the job are resumed. The reason that these models are used is to make debugging a cluster OpenMP job as similar as possible to debugging a regular OpenMP process, which also uses the "stop the world" and "all threads run" (i.e., a single-process version of "all process run") models.

In addition to providing all the commands available in MPI debugging, this support provides all the OpenMP debugging features, except that the command "show openmp thread tree" is not yet implemented.

Note that on Itanium®, this support is available only for Linux with kernel version 2.6.9 or newer.

For more information on debugging Intel® Cluster OpenMP applications and debugging parallel applications in general, see Chapter 19 of the manual.

The following applies when the debugger is packaged with Intel® compiler versions 8.x or later:

All platforms:

Itanium®:

IA-32:

Intel® 64:

Debugging multi-threaded applications

When debugging multi-threaded applications, probing mutexes and condition variables is not yet supported.

Debugging applications that fork

Debugging the child process of an application that calls fork is not yet supported.

Debugging applications that exec

The $catch_execs debugger control variable is not supported.

Snapshots

Snapshots are not yet supported as described in the manual.

Debugging optimized code

Debugging optimized code is not yet fully supported. The debugger may not be able to see some function names, parameters, variables, or the contents of the parameters and variables when code is compiled with optimizations turned on. However, the "-debug extended" option is recommended (with -O -g, for example) when compiling to debug optimized code.

Watchpoints

Watchpoints that are created to detect read access don't trigger as documented in the manual. Watchpoints that are created to detect write access don't trigger when a value identical to the value in the variable or memory location has been written. These restrictions are due to a limitation in the Linux operating system

Thread Local Storage

Variables in thread local storage are declared in a multi-threaded program with the keyword __thread. The debugger supports manipulations of these variables. However, the debugger may not correctly locate a variable in thread local storage on the Itanium� and the Intel® 64 platforms because the Intel� compilers on these platforms generate incorrect location description for such a variable. The debugger team is working with the compiler team to have this issue resolved.

Fortran modules

A globally defined Fortran module should be rescoped with a double percent (%%) when referred to. For example, to set a breakpoint in the subroutine bar contained in a globally defined module foo, do

    (idb) stop in foo%%bar

Please refer to the following section in the manual for the rescoping syntax:

GUI

This version of the debugger provides a GUI. A series of issues are noted below.

• GDB compatibility mode is not supported.


• At the bottom of the window, there is a command line combo box labeled "Enter Debugger command":
  
  • Pressing the Return key with an empty command line repeats the previous command.
  
  
  • To restore an earlier command, press the up-arrow or down-arrow key until the desired command appears, or (if unsuccessful) press the F4 key to pop up the full history list. The command can then be edited.
  
  
• The conventional flashing cursor in text-input fields is not consistently displayed in many cases.


• Watch/wait cursors are not displayed during long operations. Wait for output before proceeding.


• The source file browsing dialog box may not appear for a long time if the application's debug information describes a large number of source files.


• The text displayed in the source viewer while a large application is being loaded suggests that no application has yet been specified. A continually-changing "Loading" label in the top right hand corner confirms that the specified application is currently being loaded.


• Only an English-language version is currently available.


• Clicking the Up button, when the last or bottom stack frame is selected, causes the selection to shift to the first or top stack frame.


• Holding down a mouse button on controls does not repeat the action. Click once per desired repetition.


• Attempts to Paste into a read-only text field are silently ignored.


• If a dialog box is displayed, and then iconified, repeated attempts to display the dialog through a menu option, does not restore the dialog. Deiconify the dialog box to make it appear.


• Clicking the OK button in the New Target panel just hides the panel if no filename is displayed in the text input field. To bring back the panel, select the New Target... item from the File menu.


• The OK button in the New Target panel is disabled if text is deleted from the text input field, and it is not enabled again if a filename is chosen using the Browse... button. The OK button may be enabled by editing (eg entering and deleting) text or by hiding and restoring the panel.


• After starting the target application (by pressing the Return key or one of the Run buttons), the application may run without the debugger updating its display, either fully or partially. Restart the application until the display responds.


• Pressing the Return key after typing text in the Breakpoint Wizard does not commit the input. Click the Finish button instead.


• When using the Breakpoint wizard to create signal based breakpoints, the signal selected is not the signal that gets used (the next one in the list actually gets used). Selecting the last signal in the list results in an assertion.


• When running the target application with arguments from the command line, pressing the Run button later doesn't re-use these arguments. If you use the Run-Args pane the arguments are re-used.


• After loading a core file, use the "where" or "t" commands to view a trace of stack frames in the Debugger Output panel, and use the source viewer's Browse button to see the source code for frames other than #0.


• If the Up button does not move the selected source and stack frame up one frame, click on the desired frame in the stack-trace panel.


• Attaching to a running process a second time in a given debugger process may result in the usual buttons not being enabled. Enter the "detach" command, restart the debugger, and attach to the process again, from the new debugger.


• The GUI is not available during an MPP debugging session.


• Entering "thread <num>" in the command input area changes the current thread in the debugger, but the source and frame panes are not updated to reflect the change.

MPP Debugging Restrictions

GUI is not available for MPP debugging. Also, the debugger command "rerun" is not available.

For MPI debugging, these are the known restrictions:

1. Attaching to an Intel MPI 3.0 job is not yet implemented.
2. Using "mpiexec -idb" to start an Intel MPI 3.0 job would launch the debugger in a newly created terminal, which is dedicated to the debugger's I/O. You cannot use the debugger if your environment does not support multiple terminals.

Examining errno

In some cases (on some Linux variants), errno is treated as a per-thread entity, and is defined as a macro that does a look-up for (and then a fetch of) the actual value. In those cases, directing the debugger to examine the value of errno results in a message indicating that errno is not defined.

Function Breakpoints

On Itanium® processors, debugger breakpoints set in functions (via the "stop in" command) may not halt user program execution at the first statement. This is due to insufficient information regarding the function prolog. As a work around, use "stop at" to set a breakpoint on the desired statement.

Compilation Anomalies

Compilation with ICC using -ax{K|W|N|B|P} results in two copies of generated code for each function. One for IA32 generic code and one for CPU specific code. The symbol for each function then refers to an Auto CPU Dispatch routine that decides at run-time which one of the generated code sections to execute. Breakpoints that are set on these functions by name cause the application to stop in the dispatch routine.

Compilation using -fp causes the EBP register on IA-32 architecture be used as a frame pointer rather than a general purpose register. Debuggers and traceback handlers may not be able to properly unwind through a stack that contains a call to a function that is compiled without -fp in effect. If you compile with -g or -O0, -fp is implicitly enabled, but not if you specify a higher optimization level explicitly (such as -O2). If you intend to use the debugger or traceback on an application, and are using some level of optimization higher than -O0, you should also specify -fp to ensure that the debugger and traceback handler can use frame pointers.

GCC 3.4 & 4.0

This version of the debugger has not completed full verification against debuggable images created using GCC 3.4 or GCC 4.0. It is possible the debugger will have problems processing the debugging information for images created using this compiler, including debuggable versions of system libraries.

Issues in OpenMP Support

Here is a list of the known issues with OpenMP support:

• Inspecting shared variables in a parallel region

  The compilers may generate incorrect location information for shared variables if they are not explicitly declared shared for the parallel region. Incorrect location information for a shared variable can cause the debugger to display incorrect value for the shared variable. You can avoid this problem by explicitly declaring the shared variables in a parallel region.

• Stepping into a parallel region

  A "next" or "step" command issued at the start of a parallel region (i.e., the #pragma omp line) will execute the whole region before the command completes. To work around this problem, you can set a breakpoint inside the parallel region and then issue the "cont" command. Alternatively, you can issue the "cont to ln" command, where ln is the line number of a line inside the parallel region.

• Show all locks

  This functionality is not yet implemented. For now, you have to explicitly specify the locks you would like to inspect.

• Waiters on a lock

  Sometimes the debugger does not have enough information to figure out the IDs of the threads that are waiting on a lock. If this happens, the debugger reports "unknwon" in the Waiters field.

Source Correlation

If the debugger outputs a warning about bad source correlation (Warning: bad source correlation found in <executable>. Further instances ignored.), this is because the compiler has exposed a bug in the linker.

Execute rpm -q binutils on your machine; if it shows a version earlier than 2.14.90.0.5, install binutils 2.14.90.0.5 or later. Download (from http://www.kernel.org) the appropriate .rpm file for your machine architecture and see the associated release.binutils.<version> page for additional information.

Note that installing an updated binutls package is known to fix the problem in most, but not all, cases.

Debugging functions in shared libraries

On IA-32 processors, stepping into functions that are in shared libraries doesn’t always show the correct stack trace when executing a "where" command. In these cases, executing a "return" will not cause execution to return to the correct place. The work around is to set a breakpoint on the desired return location (e.g. “<file>”:<line>), then issue the "cont" command.

Running EL5 or Fedora Core 6

On IA-32 processors, running EL5.0 or Fedora Core, users may see

error while loading shared libraries: libstdc++.so.5: cannot open shared object file: No such file or directory

The compatibility C++ libraries should be installed in order for the debugger to function (compat-libstdc++-*).

Intel® 64 Processor Support

On the Intel® 64 platform, the debugger supports all the major features available on other platforms, and shares the same known issues and restrictions listed above.

One new feature on this platform introduced in this release is the dual-mode support, which enables the debugger to debug both the Intel® 64 processes and the 32-bit processes. However, there are two known problems with this new feature:

1. Watchpoints in the memory region above 0xffff0000 do not work because of a bug in the system call mprotect, which is invoked by the debugger to create watchpoints.
2. The pagination support (controlled by the debugger variable $page) is disabled during a MPP debugging session.

These problems will be resolved in a future release.

For full information about the debugger, please refer to the following manual:

which is found in the installation directory where these release notes reside.

Notation Conventions

Release Notes and user guide documentation use the notation conventions listed in the following table:

Style	Definition
This type style	indicates an element of syntax, a reserved word, a keyword, a file name, or part of a program example (text appears in lowercase unless UPPERCASE is required)
This type style	indicates what you type as input
This type style	indicates an argument on a command line or an option's argument
[ items ]	indicates that the items enclosed in brackets are optional
{ item | item }	indicates a set of choices from which you must select one
... (ellipses)	indicates that an argument can be repeated several times
icc	is a placeholder for a valid compiler name such as icc, icpc or ifort.

Your feedback is very important to us. If you did not register during installation, please do so at the Intel(R) Software Development Products Registration Center. Registration entitles you to free technical support, product updates and upgrades for the duration of the support term.

For information about how to find Technical Support, Product Update, Users Forum, FAQs, tips and tricks, and other support information, please visit: http://www.intel.com/software/products/support.

Note: If your distributor provides technical support for this product, please contact them for support rather than Intel.

Related Products and Services

Information on Intel software development products is available at http://www.intel.com/software/products.

Some of the related products include:

• The Intel® Software College provides training for developers on leading-edge software development technologies. Training consists of online and instructor-led courses covering all Intel architectures, platforms, tools, and technologies.
• The VTune(TM) Performance Analyzer enables you to evaluate how your application is utilizing the CPU and helps you determine if there are modifications you can make to improve your application's performance.
• The Intel® C++ and Fortran Compilers are an important part of making software run at top speeds with full support for the latest Intel Pentium® and Itanium® processors.
• The Intel® Performance Library Suite provides a set of routines optimized for various Intel processors. The Intel® Math Kernel Library, which provides developers of scientific and engineering software with a set of linear algebra, fast Fourier transforms and vector math functions optimized for the latest Intel Pentium® and Intel Itanium® processors. The Intel® Integrated Performance Primitives consists of cross-platform tools to build high performance software for several Intel architectures and several operating systems.

INFORMATION IN THIS DOCUMENT IS PROVIDED IN CONNECTION WITH INTEL(R) PRODUCTS. NO LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, TO ANY INTELLECTUAL PROPERTY RIGHTS IS GRANTED BY THIS DOCUMENT. EXCEPT AS PROVIDED IN INTEL'S TERMS AND CONDITIONS OF SALE FOR SUCH PRODUCTS, INTEL ASSUMES NO LIABILITY WHATSOEVER, AND INTEL DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY, RELATING TO SALE AND/OR USE OF INTEL PRODUCTS INCLUDING LIABILITY OR WARRANTIES RELATING TO FITNESS FOR A PARTICULAR PURPOSE, MERCHANTABILITY, OR INFRINGEMENT OF ANY PATENT, COPYRIGHT OR OTHER INTELLECTUAL PROPERTY RIGHT. UNLESS OTHERWISE AGREED IN WRITING BY INTEL, THE INTEL PRODUCTS ARE NOT DESIGNED NOR INTENDED FOR ANY APPLICATION IN WHICH THE FAILURE OF THE INTEL PRODUCT COULD CREATE A SITUATION WHERE PERSONAL INJURY OR DEATH MAY OCCUR.
Intel may make changes to specifications and product descriptions at any time, without notice. Designers must not rely on the absence or characteristics of any features or instructions marked "reserved" or "undefined." Intel reserves these for future definition and shall have no responsibility whatsoever for conflicts or incompatibilities arising from future changes to them. The information here is subject to change without notice. Do not finalize a design with this information.
The products described in this document may contain design defects or errors known as errata which may cause the product to deviate from published specifications. Current characterized errata are available on request.
Contact your local Intel sales office or your distributor to obtain the latest specifications and before placing your product order.
Copies of documents which have an order number and are referenced in this document, or other Intel literature, may be obtained by calling 1-800-548-4725, or by visiting Intel's Web Site.

Intel processor numbers are not a measure of performance. Processor numbers differentiate features within each processor family, not across different processor families. See http://www.intel.com/products/processor_number for details.

BunnyPeople, Celeron, Celeron Inside, Centrino, Centrino logo, Core Inside, FlashFile, i960, InstantIP, Intel, Intel logo, Intel386, Intel486, Intel740, IntelDX2, IntelDX4, IntelSX2, Intel Core, Intel Inside, Intel Inside logo, Intel. Leap ahead., Intel. Leap ahead. logo, Intel NetBurst, Intel NetMerge, Intel NetStructure, Intel SingleDriver, Intel SpeedStep, Intel StrataFlash, Intel Viiv, Intel vPro, Intel XScale, IPLink, Itanium, Itanium Inside, MCS, MMX, Oplus, OverDrive, PDCharm, Pentium, Pentium Inside, skoool, Sound Mark, The Journey Inside, VTune, Xeon, and Xeon Inside are trademarks of Intel Corporation in the U.S. and other countries.

* Other names and brands may be claimed as the property of others.

Copyright (C) 2002-2007, Intel Corporation. All rights reserved.

Portions Copyright © 2001 Hewlett-Packard Development Company, L.P.