Overview
Product Contents
Special Features
New Features
Installation Notes
Known Limitations
Documentation
Technical Support
Additional Information
Copyright and Legal Information
To receive technical support and updates, you need to register your Intel Software Product. See the Technical Support section.
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.
A GUI is now available. Just use the -gui flag when
invoking the debugger from the Linux command line.
Users who prefer the GDB command line interface have the option of switching on the GDB-like interface. The GDB command set and debugger output are supported as described in the manual. To activate GDB mode, use the -gdb invocation command line option, or set the debugger variable $cmdset to gdb after starting the debugger, e.g.:
(idb) set $cmdset="gdb"
Debugging MPI applications compiled with mpich
or Intel MPI 3.0 is supported to the extent described in the manual
(Section Debugging Parallel Applications).
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.
idb -gdb -fullname
To use the GDB-like interface, do not load the idb.el file
documented in the manual.
When debugging an OpenMP application, the debugger is capable of providing useful information on OpenMP locks, teams, and threads.
You may wish to swap the bytes of a numeric value, rather than rely
on the debugger's knowledge of representation. The "%" unary
operator reverses the order of the bytes of its integer operand.
For example:
(idb) printx % (short) 0x0102, % (int) 0x0102
0x0201 0x02010000
(idb) printx % (short) 0x0102
0x0201
The GDB compatibility mode is now available for debugging your MPI-1 applications. In this mode, you can use not only the regular GDB commands but also the parallel debugging commands discussed in the section Debugging Parallel Applications in the manual to facilitate your debugging. You can invoke the GDB compatibility mode either by specifying the flag -gdb at the command line or by setting the debugger variable $cmdset to "gdb".
The debugger is now capable of debugging a fresh MPI job that uses the MPICH or the Intel MPI 3.0 libraries. In additon, 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:
% 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.
% 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.
In some cases it is impossible to debug an application on the same machine that the user is working on. For example, an application could be running on a mobile device or be part of the kernel. In these cases you can still debug. This is done by running the debugger on the host machine and connecting idb to a special remote agent on the target machine. It is important to have the same application binaries on the target and host machines, but the binary on the target machine may be stripped: it will still be debugable.
The gdbserver utility is used as the remote agent. This utility is part of the GNU* debugger, GDB*. GDB* and gdbserver communicate using a special Remote Serial Line protocol which the debugger understands. The debugger and gdbserver can be connected with a TCP/IP connection.
To start your remote application under debugger control, you need to
activate the GNU* gdbserver
remote agent and have it launch the actual application.
For a complete description of
gdbserver see
The GDB manual. Here is an example showing how to invoke it:
% gdbserver [<host>]:<port> application [application arguments]
When an application is launched by gdbserver,
gdbserver,
service information about the
started application and the connection is displayed in the terminal
window.
Then you can issue the following command in a shell session
on the host machine to connect to the
remote gdbserver :
% $IDB_HOME/idb [idb options] -remote [<host>]:<port> application [application arguments]
or
% $IDB_HOME/idb [idb options] -remote [<host>]:<port>
The debugger will establish a connection
with gdbserver and stops when
gdbserver stops, and at the same location.
The debugger supports the following remote debugging commands:
It is important to have the same application binaries on the target
and host machines. However, the binary on the target machine may
be stripped, but it will still be debuggable.
The same version of the operating system should be used on the host and
remote machines. This is because shared libraries could have
different relocation tables and there is no way for the debugger
to discover these differences.
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:
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".
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.
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
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.
See Known Limitations for a list of issues with OpenMP support.
The Intel C++ Compiler for Linux* includes a debugger integration
with Eclipse* 3.1 & 3.1.1, and the C/C++ Development Tools*
(CDT) 3.0 & 3.0.1. This
functionality is an optional 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.
Full details can be found in the
which is found in the installation directory where these release notes reside.
source <install-dir-path>/bin/idbvars.sh (.csh)
When debugging multi-threaded applications, probing mutexes and condition variables is not yet supported.
Debugging multi-process applications is not yet supported. This includes debugging the child process of an application that calls fork.
Snapshots are not yet supported as described in the manual.
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 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
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® EM64T 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.
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:
This version of the debugger provides a GUI. A series of
issues are noted below.
GUI is not available for MPP debugging. Also, the debugger command
"rerun" is not available.
For MPI debugging, these are the known restrictions:
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.
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.
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 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 IA-32 EBP register 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.
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.
Here is a list of the known issues with OpenMP support:
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.
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.
This functionality is not yet implemented. For now, you have to explicitly specify the locks you would like to inspect.
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.
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.
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.
On IA-32 processors, running
Red Hat* 8.0, Red Hat* 9.0, or Fedora Core, the
compatibility C++ libraries should be installed in order for the
debugger to function (compat-libstdc++-*).
On the Intel® EM64T 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® EM64T processes and the 32-bit processes. However, there are two known problems with this new feature:
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.
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. |
NOTE: Registering for support varies for release product or pre-release products (alpha, beta, etc) - only released products have support web pages on http://support.intel.com/.
To register for an account, please visit the Intel® Registration Center web site at http://www.intel.com/software/products/registrationcenter/index.htm. If you have forgotten your password, please email a request to: quadsupport@mailbox.intel.com. Please do not email your technical issue to this email address.
When submitting problems or issues, please include a reproducer that is as complete as possible.
Information on Intel software development products is available at http://www.intel.com/software/products.
Some of the related products include:
INFORMATION IN THIS DOCUMENT IS PROVIDED IN CONNECTION WITH INTELŪ 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. Intel products are not intended for use in medical, life saving, life sustaining, critical control or safety systems, or in nuclear facility applications. Intel may make changes to specifications and product descriptions at any time, without notice.
The software described in this document may contain software defects which may cause the product to deviate from published specifications. Current characterized software defects are available on request.
This document as well as the software described in it is furnished under license and may only be used or copied in accordance with the terms of the license. The information in this manual is furnished for informational use only, is subject to change without notice, and should not be construed as a commitment by Intel Corporation. Intel Corporation assumes no responsibility or liability for any errors or inaccuracies that may appear in this document or any software that may be provided in association with this document.
Except as permitted by such license, no part of this document may be reproduced, stored in a retrieval system, or transmitted in any form or by any means without the express written consent of Intel Corporation.
Developers must not rely on the absence or characteristics of any features or instructions marked "reserved" or "undefined." Improper use of reserved or undefined features or instructions may cause unpredictable behavior or failure in developer's software code when running on an Intel processor. Intel reserves these features or instructions for future definition and shall have no responsibility whatsoever for conflicts or incompatibilities arising from their unauthorized use.
BunnyPeople, Celeron, Celeron Inside, Centrino, Centrino logo, Chips, Core Inside, Dialogic, EtherExpress, ETOX, FlashFile, i386, i486, i960, iCOMP, 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 XScale, IPLink, Itanium, Itanium Inside, MCS, MMX, MMX logo, Optimizer logo, OverDrive, Paragon, PDCharm, Pentium, Pentium II Xeon, Pentium III Xeon, Performance at Your Command, Pentium Inside, skoool, Sound Mark, The Computer Inside., The Journey Inside, VTune, Xeon, Xeon Inside and Xircom are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries.
* Other names and brands may be claimed as the property of others.
Copyright © 2002-2006, Intel Corporation.
Portions © 2001 Hewlett-Packard Development Group, L.P.
All Rights Reserved.