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, or life sustaining applications.
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.
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 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.
Intel SpeedStep, Intel Thread Checker, Celeron, Dialogic, i386, i486, iCOMP, Intel, Intel logo, Intel386, Intel486, Intel740, IntelDX2, IntelDX4, IntelSX2, Intel Inside, Intel Inside logo, Intel NetBurst, Intel NetStructure, Intel Centrino, Intel Xeon, Intel XScale, Itanium, MMX, MMX logo, Pentium, Pentium II Xeon, Pentium III Xeon, Pentium M, and VTune 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® Intel Corporation 2002-2005.
Portions © 2001 Hewlett-Packard Development Group, L.P.
load, unload, and file Commands
run and rerun Commands
kill Command
attach and the detach Commands
fork()
exec()
quiet Specifier
exec(),
fork(), dlopen() and dlclose() System Calls
The Intel® Debugger is a full-featured symbolic source code debugger with a command-line interface and a basic graphical user interface. You can use it to make your applications run more efficiently and to locate programming errors in your code.
The debugger provides support (at various levels depending on compiler version) for debugging programs written in C, C++, and Fortran (77, 90 and 95).
When you purchase Intel® C, Intel® C++ or Intel® Fortran the Intel® Debugger is included on the kit.
In addition, kits, documentation, and answers to frequently asked questions are available from the following sources:
This manual is intended for programmers who have a working knowledge of one of the programming languages that Intel IDB supports (C, C++, Fortran).
This manual is organized as follows:
corefile_listobj.c example.
The following documents contain related information:
TBD.
Please provide the following information when you enter your problem report. Doing so will make it easier for us to reproduce and analyze your problem. If you do not provide this information, we may have to ask you for it.
A description of the problem. The clearer and more detailed the description, the easier it will be for us to reproduce and analyze your problem.
A transcript of the debugger output. You can obtain this by using the
record io debugger command or by using the
script(1) system command.
Operating system and version information. The output of uname -a
is best.
Version information. The version number is in the welcome banner that
displays when you invoke the debugger. You can also obtain the version number by
invoking the debugger with the idb -V command.
The smallest source code example possible;
build instructions (a Makefile is preferable);
source languages, compiler versions, and so forth; and a pointer to
a tar
file containing sources or binaries that reproduce the problem.
To obtain compiler versions, you can use the -V option if your compiler
supports it (see the reference page for your compiler).
Alternatively, you can generate the output of /usr/sbin/setld -i showing
the installed compiler subsets.
The exact debugger commands that cause the problem to occur.
Any other information that you think would be helpful.
The debugger development team can use ftp to fetch sources and executables
if you can place them in an anonymous FTP area. If not, you may be asked
to use another method.
The following conventions are used in this manual:
| Convention | Meaning |
|---|---|
%
|
A percent sign represents the C shell system prompt. |
#
|
A pound sign represents the default superuser prompt. |
|
UPPERCASE lowercase |
The operating system differentiates between lowercase and uppercase characters. On the operating system level, you must type examples, syntax descriptions, function definitions, and literal strings that appear in text exactly as shown. |
| Ctrl/C | This symbol indicates that you must press the Ctrl key while you simultaneously press another key (in this case, C). |
monospaced text
|
This typeface indicates a routine, partition, pathname, directory, file, or non-terminal name. This typeface is also used in interactive examples. |
monospaced bold text
|
In interactive examples, this typeface indicates input that you enter. In syntax statements and text, this typeface indicates the exact name of a command or keyword. |
monospaced italic text
|
Monospaced italic type indicates variable values, place holders,
and function argument names. In syntax definitions, monospaced italic text indicates non-terminal names. When a non-terminal name consists of more than one word, the words are joined using the underscore ( _), for example,
breakpoint_command.
|
| italic text | Italic type indicates book names or emphasized terms. |
foo_bar
: item1
| item2
| item3
|
A colon (:) starts the syntax definition of a non-terminal name (in this example,
foo_bar. Vertical
bars (|) separating items that appear in syntax definitions indicate
that you choose one item from among those listed.
|
[ ]
|
In syntax definitions, brackets indicate items that are optional. |
option ;...option ,...option ...
|
A set of three horizontal ellipses indicates that you can enter additional parameters, options, or values. A semicolon, comma, or space preceding the ellipses indicates successive items must be separated by semicolons, commas, or spaces. |
idb(1)
|
Cross-references to online reference pages include the appropriate
section number in parentheses. For example,
idb(1)
indicates that you can find the material on the
idb
command in Section 1 of the reference pages. The man
command % man 1 idb shows the reference page for
this command.
|
Part I provides information you need to rapidly make simple use of the debugger.
Intel IDB supports DBX and GDB modes. By default, IDB operates like the the DBX debugger. In the GDB mode, Intel IDB operates like the GNU* Debugger, GDB*. See the Starting the Debugger section to get to know how to launch the debugger in the required mode.
You look for a bug by doing the following:
Compile and link your program using the -g switch.
% icc -g tmp.c
For more details see Preparing the Compiler and Linker Environment.
Before you start the debugger, make sure that you have correctly set the size information for your terminal; otherwise, the debugger's command line editing support may act unpredictably. For example, if your terminal is 25x80, you may need to set the following:
% stty rows 25 ; setenv LINES 25 % stty cols 80 ; setenv COLS 80
There are four basic alternatives for running the debugger on a process (see examples below):
Intel IDB starts operating in DBX mode by default, so you do not have to specify any special options in the shell command line.
Examples:
Creating the process using the shell command line.
% idb a.out Linux Application Debugger for ..., Version ..., Build ... ------------------ object file name: a.out Reading symbolic information ...done (idb) stop in main [#1: stop in int main(void) ] (idb) run
Creating the process using the debugger commands.
% idb Linux Application Debugger for ..., Version ..., Build ... ------------------ (idb) load a.out Reading symbolic information ...done (idb) stop in main [#1: stop in int main(void) ] (idb) run
Ataching to a running process using shell command line.
% ./a.out & [1] 27859 % jobs [1]+ Running ./a.out & % idb a.out -pid 27859 Linux Application Debugger for ..., Version ..., Build ... ------------------ Reading symbolic information ...done Attached to process id 27859 ....
Press Ctrl/C to interrupt the process.
Attaching to the process using the debugger commands.
% ./a.out & [1] 27859 % jobs [1]+ Running ./a.out & % idb Linux Application Debugger for ..., Version ..., Build ... ------------------ (idb) attach 27859 a.out Reading symbolic information ...done Attached to process id 27859 ....
Press Ctrl/C to interrupt the process.
To start the debugger in the GDB mode, specify -gdb option in the
shell command
line.
Examples:
Creating the process using the shell command line.
% idb -gdb a.out Linux Application Debugger for ..., Version ..., Build ... ------------------ object file name: a.out Reading symbols from a.out...done (idb) break main Breakpoint 1 at 0x80484f6: file qwerty.c, line 9. (idb) run
Creating the process using the debugger commands.
% idb -gdb Linux Application Debugger for ..., Version ..., Build ... ------------------- (idb) file a.out Reading symbols from a.out...done. (idb) break main Breakpoint 1 at 0x80484f6: file qwerty.c, line 9. (idb) run
Ataching to a running process using shell command line.
% ./a.out & [1] 27859 % jobs [1]+ Running ./a.out & % idb -gdb a.out -pid 27859 Linux Application Debugger for ..., Version ..., Build ... ------------------ object file name: a.out Reading symbols from a.out...done. Attached to process id 27859 ....
Press Ctrl/C to interrupt the process.
Attaching to the process using the debugger commands.
% ./a.out & [1] 27859 % jobs [1]+ Running ./a.out & % idb -gdb Linux Application Debugger for ..., Version ..., Build ... (idb) file a.out Reading symbols from a.out...done. (idb) attach 27859 Attached to process id 27859 ....
Press Ctrl/C to interrupt the process.
Note: In the case of Fortran, routine main at which your
program stops is not your main program unit. Rather, it is a main routine
supplied by the Fortran system that performs some initialization and then
calls your code. Just step forward using the step
command a couple of times (probably twice) and
you will soon step into your code.
Note: If you want full compatibility with GDB output, you need
to set the debugger variable $gdb_compatible_output
to 1. Otherwise, IDB will produce the extended GDB output in some cases.
The debugger issues a prompt when it is ready for the next command from the terminal:
(idb) you type here
When you enter commands, you use the left and right arrow keys to move within the line and the up and down arrow keys to recall previous commands for editing. When you finish entering a command, press the Enter key to submit the completed line to the debugger for processing.
You can continue a line by ending the line to be continued with a
backslash (\)
character.
On a blank line, press the Enter key to re-execute the most-recent valid command.
Following are two very useful commands available in both modes:
(idb) help (idb) quit
To execute debugger commands from a script, use the source
command as follows:
(idb) source filename
The source command causes the debugger to read and execute
debugger commands from filename.
The source command is not yet available in the GDB mode.
Although the debugger supports debugging multiple processes, it operates only on a single process at a time, known as the current process.
Processes contain one or more threads of execution. The threads execute functions. Functions are sequences of instructions that come from source lines within source files.
As you enter debugger commands to manipulate your process, it would be very tedious to have to repeatedly specify which thread, source file, and so on you wish the command to be applied to. To prevent this, each time the debugger stops the process, it re-establishes a static context and a dynamic context for your commands. The components of the static context are independent of this run of your program; the components of the dynamic context are dependent on this run.
You can change most of these individually to point to other instances, as described in the relevant portions of this manual, and the debugger will modify the rest of the static and dynamic context to keep the various components consistent.
As was shown previously, you can tell the debugger to create a process or to attach to an existing process.
After you specify the program (either on the
shell
command line or
by using the load(dbx)
or file(gdb) command),
but before you have requested the debugger to
create the process, you can still do things that seem to require a running
process; for example, you can create breakpoints and examine sources. Any breakpoints
that you create will be inserted into the process as soon as possible after it
executes your program.
To have the debugger create a process (rather than attach to an existing process), you request it to run, specifying, if necessary, any arguments and input and output redirection as follows:
% idb a.out Linux Application Debugger for ..., Version ..., Build ... ...Preparing the Compiler and Linker Environment> (idb) run
or
(idb) run arguments
or
(idb) run arguments > output-file
or
(idb) run arguments < input-file > output-file
The result of using any of the preceding command variations is similar to having attached to a running process.
Following are the most common ways to pause a process:
Pressing Ctrl/C.
(idb) run
^C
Interrupt (for process)
Stopping process localhost:27903 (a.out).
Thread received signal INT
stopped at [int main(int):5 0x120001138]
5 while (argc < 2 && i < 10000000)
Waiting until the process raises a signal.
Creating a breakpoint before running or continuing the process.
(idb) stop in main
[#1: stop in int main(void)]
(idb) run
[1] stopped at [int main(void):182 0x1200023f8]
182 List<Node> nodeList;
Creating a watchpoint before running or continuing the process.
(idb) watch variable nodeList._firstNode write
[#2: watch variable nodeList._firstNode write]
(idb) cont
[2] Address 0xbffec2b4 was accessed at:
void List<Node>::append(class Node* const): src/x_list.cxx
[line 149, 0x804e181] append(class Node* const)+0x15: movl %edx, (%eax)
0xbffec2b4: Old value = 0x00000000
0xbffec2b4: New value = 0x0805ccf0
[2] stopped at [void List<Node>::append(class Node* const):149 0x0804e183]
149 _firstNode = node;
Pressing Ctrl/C.
(idb) run ^C Interrupt (for process) Stopping process localhost:27903 (a.out). Thread received signal INT main(argc=1) at x_whatHappensOnControlC.cxx: 5 5 while (argc < 2 && i < 10000000)
Waiting until the process raises a signal.
(idb) run Starting program: /users/apavlenk/prj/anmod.cvs/test/idb/Examples/exp/i686-Linux/debuggable/x_segv Thread received signal SEGV buggy (input=0xbfffec0f "/users/apavlenk/prj/anmod/test/idb/Examples/exp/i686-Linux/debuggable/x_segv", output=0x0) at src/x_segv.cxx:13 13 output[k] = input[k];
Creating a breakpoint before running or continuing the process.
(idb) break main Breakpoint 1 at 0x8049f70: file x_list.cxx, line 182. (idb) run Starting program: /usr/examples/x_list Breakpoint 1, main () at x_list.cxx:182 182 List<Node> nodeList;
Creating a watchpoint before running or continuing the process.
(idb) watch nodeList._firstNode Hardware watchpoint 2: nodeList._firstNode (idb) continue Continuing. Old value = (class Node *) 0x0 New value = (class Node *) 0x805ccf0 Hardware watchpoint 2: nodeList._firstNode List<Node>::append (this=0xbffeb794, node=0x805ccf0) at src/x_list.cxx:149 149 _firstNode = node;
This section describes how to examine components of the paused process.
You can perform the following operations on source files:
Following is an example that shows listing lines and using the
/ command to search for a string:
(idb) file
src/x_list.cxx
(idb) list 180:10
180 main()
181 {
182 List<Node> nodeList;
183
184 // add entries to list
185 //
> 186 IntNode* newNode = new IntNode(1);
187 nodeList.append(newNode); {static int somethingToReturnTo; somethingToReturnTo++; }
188
189 CompoundNode* cNode = new CompoundNode(12.345, 2);
(idb) /CompoundNode
192 CompoundNode* cNode1 = new CompoundNode(3.1415, 7);
Aliases are shorthand forms of longer commands.
This example shows using the W alias, which lists up to 20 lines
around the current line. Note that a right bracket (>) marks the current line.
(idb) alias W
W list $curline - 10:20
(idb) W
176
177
178 // The driver for this test
179 //
180 main()
181 {
182 List<Node> nodeList;
183
184 // add entries to list
185 //
> 186 IntNode* newNode = new IntNode(1);
187 nodeList.append(newNode);
188
189 CompoundNode* cNode = new CompoundNode(12.345, 2);
190 nodeList.append(cNode);
191
192 nodeList.append(new IntNode(3));
193
194 IntNode* newNode2 = new IntNode(4);
195 nodeList.append(newNode2);
Use info source,
info line,
and list commands for looking at
source files:
(idb) info source
Current source file is src/x_list.cxx
(idb) list 180,+10
180 main()
181 {
182 List<Node> nodeList;
183
184 // add entries to list
185 //
186 IntNode* newNode = new IntNode(1);
187 nodeList.append(newNode); {static int somethingToReturnTo; somethingToReturnTo++; }
188
189 CompoundNode* cNode = new CompoundNode(12.345, 2);
(idb) forward-search CompoundNode
192 CompoundNode* cNode1 = new CompoundNode(3.1415, 7);
In a multithreaded application, you can
obtain information about the thread that
stopped or about all the threads, and you can
then change the context to look more closely
at a different thread. Note that a right bracket (>) marks the current thread.
And the asterisk (*) marks the thread with return status.
(idb) thread
Thread Name State Substate Policy Pri
------ ------------------------- --------------- ----------- ------------ ---
>* 1 default thread running VP 3 SCHED_OTHER 19
(idb) show thread
Thread Name State Substate Policy Pri
------ ------------------------- --------------- ----------- ------------ ---
>* 1 default thread running VP 3 SCHED_OTHER 19
-1 manager thread blk SCS SCHED_RR 19
-2 null thread for slot 0 running VP 1 null thread -1
-3 null thread for slot 1 ready VP 3 null thread -1
-4 null thread for slot 2 new new null thread -1
-5 null thread for slot 3 new new null thread -1
2 threads(0x140000798) blocked cond 3 SCHED_OTHER 19
3 threads+8(0x1400007a0) blocked cond 3 SCHED_OTHER 19
4 threads+16(0x1400007a8) blocked cond 3 SCHED_OTHER 19
5 threads+24(0x1400007b0) blocked cond 3 SCHED_OTHER 19
6 threads+32(0x1400007b8) blocked cond 3 SCHED_OTHER 19
You can select any thread to be the focus of commands that show things. For example:
(idb) thread 2 Thread Name State Substate Policy Pri ------ ------------------------- --------------- ----------- ------------ --- > 2 threads(0x140000798) blocked cond 3 SCHED_OTHER 19
(idb) thread ID State >* 8 stopped (idb) show thread ID State 1 stopped 2 stopped 3 stopped 4 stopped 5 stopped 6 stopped 7 stopped >* 8 stoppedThis command provides the following information about known threads:
LinuxThreads has a PID for each thread in a multithreaded application.
You can select any thread to be the focus of commands that show things. For example:
(idb) thread 2 ID State > 2 stopped
You can examine the call stack of any thread. Even if you are not using threads explicitly, your process will have one thread running your code. You can move up and down the stack, and examine the source being executed at each call.
(idb) where 3
>0 0x0804b644 in ((IntNode*)0x805c5b0)->IntNode::printNodeData() "src/x_list.cxx":94
#1 0x0804da73 in ((List<Node>*)0xbffec53c)->List<Node>::print() "src/x_list.cxx":168
#2 0x0804b444 in main() "src/x_list.cxx":203
(idb) up 2
>2 0x0804b444 in main() "src/x_list.cxx":203
203 nodeList.print();
(idb) list $curline - 3:5
200 CompoundNode* cNode2 = new CompoundNode(10.123, 5);
201 nodeList.append(cNode2); {static int somethingToReturnTo; somethingToReturnTo++; }
202
> 203 nodeList.print();
204 }
(idb) down 1
>1 0x0804da73 in ((List<Node>*)0xbffec53c)->List<Node>::print() "src/x_list.cxx":168
168 currentNode->printNodeData();
(idb) backtrace 3
#0 0x0804b644 in IntNode::printNodeData (this=0x805c5b0) at src/x_list.cxx:94
#1 0x0804da73 in List<Node>::print (this=0xbffebd2c) at src/x_list.cxx:168
#2 0x0804b444 in main () at src/x_list.cxx:203
(idb) up 2
#2 0x0804b444 in main () at src/x_list.cxx:203
203 nodeList.print();
(idb) list 200,+5
200 CompoundNode* cNode2 = new CompoundNode(10.123, 5);
201 nodeList.append(cNode2); {static int somethingToReturnTo; somethingToReturnTo++; }
202
203 nodeList.print();
204 }
(idb) down 1
#1 0x0804da73 in List<Node>::print (this=0xbffebd2c) at src/x_list.cxx:168
168 currentNode->printNodeData();
You can look at variables
and evaluate expressions involving them by using the
print command.
(idb) print fdata
12.3450003
(idb) print idata
2
(idb) print idata + 59
61
(idb) print this
0x8068f38
(idb) print *this
class CompoundNode {
_fdata = 12.3450003;
_data = 2; // class IntNode
_nextNode = 0x0; // class IntNode::Node
}
(idb) print fdata
$2 = 12.345
(idb) print idata
$3 = 2
(idb) print idata + 59
$4 = 61
(idb) print this
$5 = (class CompoundNode *) 0x8068f38
(idb) print *this
$6 = {<IntNode> = {<Node> = {_nextNode = 0x0}, _data = 2}, _fdata = 12.345}
The p is a shortcut,
and the inspect command is a synonym
for the print command.
The debugger shows you the signal that stopped the thread.
(idb) run
Thread received signal SEGV
stopped at [void buggy(char*, char*):13 0x8048b79]
13 output[k] = input[k];
Information: idb allows you to restart the execution of your program
from saved positions. Enter "help snapshot" for details.
(idb) run Starting program: /users/apavlenk/prj/anmod.cvs/test/idb/Examples/exp/i686-Linux/debuggable/x_segv Thread received signal SEGV buggy (input=0xbfffbc0f "/users/apavlenk/prj/anmod/test/idb/Examples/exp/i686-Linux/debuggable/x_segv", output=0x0) at src/x_segv.cxx:13 13 output[k] = input[k];
You can print memory as instructions or as data.
In the following example, the
wi alias lists machine instructions
before and after the current instruction. Note that the asterisk (*)
marks the current instruction.
(idb) alias wi wi ($curpc - 20)/10 i (idb) wi CompoundNode::CompoundNode(float, int): x_list.cxx [line 105, 0x120002348] cpys $f17,$f17,$f0 [line 105, 0x12000234c] bis r31, r18, r8 [line 101, 0x120002350] bis r31, r19, r16 [line 101, 0x120002354] bis r31, r8, r17 [line 101, 0x120002358] bsr r26, IntNode::IntNode(int) *[line 101, 0x12000235c] ldq r18, -32712(gp) [line 101, 0x120002360] lda r18, 48(r18) [line 101, 0x120002364] stq r18, 8(r19) [line 101, 0x120002368] sts $f0, 24(r19) [line 106, 0x12000236c] bis r31, r19, r0 (idb) $pc/10x 0x12000235c: 0x8038 0xa65d 0x0030 0x2252 0x0008 0xb653 0x0018 0x9813 0x12000236c: 0x0400 0x47f3 (idb) $pc/6xx 0x12000235c: 0xa65d8038 0x22520030 0xb6530008 0x98130018 0x12000236c: 0x47f30400 0x47f5041a (idb) $pc/2X 0x12000235c: 0x22520030a65d8038 0x98130018b6530008
Use the x command to dump memory in various
formats.
The disassemble command also provides disassembling
capability.
(idb) x /10i $pc 0x8049973 <main+27>: pushl %edi 0x8049974 <main+28>: leal -212(%ebp), %eax 0x804997a <main+34>: movl %eax, (%esp) 0x804997d <main+37>: call 0x804a2f8 <_ZN4ListI4NodeEC1Ev> 0x8049982 <main+42>: addl $0x4, %esp 0x8049985 <main+45>: movl $0x0, -200(%ebp) 0x804998f <main+55>: pushl %edi 0x8049990 <main+56>: movl $0xc, (%esp) 0x8049997 <main+63>: call 0x8049790 <_init+792> 0x804999c <main+68>: addl $0x4, %esp (idb) x /10xh $pc 0x8049973 <main+27>: 0x8d57 0x2c85 0xffff 0x89ff 0x2404 0x76e8 0x0009 0x8300 0x8049983 <main+43>: 0x04c4 0x85c7 (idb) x /6xw $pc 0x8049973 <main+27>: 0x2c858d57 0x89ffffff 0x76e82404 0x83000009 0x8049983 <main+43>: 0x85c704c4 0xffffff38 (idb) x /2xg $pc 0x8049973 <main+27>: 0x89ffffff2c858d57 0x8300000976e82404
To examine individual registers, use the print command
with name of register prepended with the dollar sign ($). Commands showing all
(or a subset of) the registers are specific for the mode; see examples below.
To look at all the
registers, use the printregs
command. For example:
(idb) print $eax 1 (idb) printx $eax 0x1 (idb) printregs $eax 0x1 1 $ecx 0x8068438 134644792 $edx 0xbfffd52c -1073752788 $ebx 0x4213030c 1108542220 $esp [$sp] 0xbfffd3e0 -1073753120 $ebp 0xbfffd4b8 -1073752904 $esi 0x40013020 1073819680 $edi 0xbfffd524 -1073752796 $eip [$pc] 0x8049973 134519155 $eflags 0x200282 2097794 $cs 0x23 35 $ss 0x2b 43 $ds 0x2b 43 $es 0x2b 43 $fs 0x0 0 $gs 0x0 0 $orig_eax 0xffffffff -1 $fctrl 0x37f 895 $fstat 0x0 0 $ftag 0x0 0 $fiseg 0x0 0 $fioff 0x0 0 $foseg 0x0 0 $fooff 0x0 0 $fop 0x0 0 $f0 0x00000000000000000000000000000000 0 $f1 0x00000000000000000000000000000000 0 $f2 0x00000000000000000000000000000000 0 $f3 0x00000000000000000000000000000000 0 $f4 0x00000000000000000000000000000000 0 $f5 0x00000000000000000000000000000000 0 $f6 0x00000000000000000000000000000000 0 $f7 0x00000000000000000000000000000000 0 $xmm0 0x00000000000000000000000000000000 $xmm1 0x00000000000000000000000000000000 $xmm2 0x00000000000000000000000000000000 $xmm3 0x00000000000000000000000000000000 $xmm4 0x00000000000000000000000000000000 $xmm5 0x00000000000000000000000000000000 $xmm6 0x00000000000000000000000000000000 $xmm7 0x00000000000000000000000000000000 $mxcsr 0x1f80 8064 $vfp 0xbfffd4b8 0xbfffd4b8
The following commands allow you to examine sets of registers:
info registers
For example:
(idb) print $sp $11 = 1 (idb) print /x $sp $12 = 0x1 (idb) info registers $eax 0x1 1 $ecx 0x8068438 134644792 $edx 0xbfffea8c -1073747316 $ebx 0x4213030c 1108542220 $esp [$sp] 0xbfffe940 -1073747648 $ebp 0xbfffea18 -1073747432 $esi 0x40013020 1073819680 $edi 0xbfffea84 -1073747324 $eip [$pc] 0x8049973 134519155 $eflags 0x200282 2097794 $cs 0x23 35 $ss 0x2b 43 $ds 0x2b 43 $es 0x2b 43 $fs 0x0 0 $gs 0x0 0 $orig_eax 0xffffffff -1 $fctrl 0x37f 895 $fstat 0x0 0 $ftag 0x0 0 $fiseg 0x0 0 $fioff 0x0 0 $foseg 0x0 0 $fooff 0x0 0 $fop 0x0 0 $f0 0x00000000000000000000000000000000 0 $f1 0x00000000000000000000000000000000 0 $f2 0x00000000000000000000000000000000 0 $f3 0x00000000000000000000000000000000 0 $f4 0x00000000000000000000000000000000 0 $f5 0x00000000000000000000000000000000 0 $f6 0x00000000000000000000000000000000 0 $f7 0x00000000000000000000000000000000 0 $xmm0 0x00000000000000000000000000000000 $xmm1 0x00000000000000000000000000000000 $xmm2 0x00000000000000000000000000000000 $xmm3 0x00000000000000000000000000000000 $xmm4 0x00000000000000000000000000000000 $xmm5 0x00000000000000000000000000000000 $xmm6 0x00000000000000000000000000000000 $xmm7 0x00000000000000000000000000000000 $mxcsr 0x1f80 8064 $vfp 0xbfffea18 0xbfffea18
After you are satisfied that you understand what is going on, you can move the process forward and see what happens. The following table shows the aliases and commands you can use to do this.
| Desired Behavior | Alias | Command | Can Take Repeat Count |
|---|---|---|---|
| Continue until another interesting thing happens |
c
|
cont
|
Yes* |
| Single step by line, but step over calls |
n
|
next
|
Yes |
| Single step to a new line, stepping into calls |
s
|
step
|
Yes |
| Continue until control returns to the caller | None |
return(dbx),
finish(gdb)
|
No |
| Single step by instruction, over calls |
ni
|
nexti
|
Yes |
| Single step by instruction, into calls |
si
|
stepi
|
Yes |
* In GDB mode repeat count has a different meaning for the
cont command. For the other commands repeat
count has the same meaning in both modes.
The following examples demonstrate stepping through lines of source code (dbx) (gdb) and stepping at the instruction level (dbx) (gdb).
Stepping through lines of source code:
(idb) list $curline - 10:20
172
173 if (i == 1) cout << "The list is empty ";
174 cout << endl << endl;
175 }
176
177
178 // The driver for this test
179 //
180 main()
181 {
> 182 List<Node> nodeList;
183
184 // add entries to list
185 //
186 IntNode* newNode = new IntNode(1);
187 nodeList.append(newNode); {static int somethingToReturnTo; somethingToReturnTo++; }
188
189 CompoundNode* cNode = new CompoundNode(12.345, 2);
190 nodeList.append(cNode); {static int somethingToReturnTo; somethingToReturnTo++; }
191
(idb) next
stopped at [int main(void):186 0x0000000000400bf6]
186 IntNode* newNode = new IntNode(1);
(idb) next 3
stopped at [int main(void):190 0x0000000000400dc8]
190 nodeList.append(cNode); {static int somethingToReturnTo; somethingToReturnTo++; }
(idb) step
stopped at [void List<Node>::append(class Node* const):148 0x0000000000401798]
148 if (!_firstNode)
(idb) list $curline - 2:6
146 {
147
> 148 if (!_firstNode)
149 _firstNode = node;
150 else {
151 Node* currentNode = _firstNode;
(idb) next
stopped at [void List<Node>::append(class Node* const):151 0x00000000004017c8]
151 Node* currentNode = _firstNode;
(idb) list $curline - 2:5
149 _firstNode = node;
150 else {
> 151 Node* currentNode = _firstNode;
152 while (currentNode->getNextNode())
153 currentNode = currentNode->getNextNode();
(idb) return
stopped at [int main(void):190 0x0000000000400de1]
190 nodeList.append(cNode); {static int somethingToReturnTo; somethingToReturnTo++; }
(idb) next 2
stopped at [int main(void):193 0x0000000000400ebc]
193 nodeList.append(cNode1); {static int somethingToReturnTo; somethingToReturnTo++; }
Stepping at the instruction level:
(idb) $pc/2i
int main(void): src/x_list.cxx
*[line 193, 0x0000000000400ed0] main+0x2f8: call append(class Node* const)
[line 193, 0x0000000000400ed5] main+0x2fd: addl $0x1, -4293911744(%rip)
(idb) nexti
stopped at [int main(void):193 0x0000000000400ed5] main+0x2fd: addl $0x1, -4293911744(%rip)
(idb) $pc/1i
int main(void): src/x_list.cxx
*[line 193, 0x0000000000400ed5] main+0x2fd: addl $0x1, -4293911744(%rip)
(idb) rerun
Process has exited
[3] stopped at [int main(void):193 0x0000000000400ed0]
193 nodeList.append(cNode1); {static int somethingToReturnTo; somethingToReturnTo++; }
(idb) $pc/2i
int main(void): src/x_list.cxx
*[line 193, 0x0000000000400ed0] main+0x2f8: call append(class Node* const)
[line 193, 0x0000000000400ed5] main+0x2fd: addl $0x1, -4293911744(%rip)
(idb) stepi
stopped at [void List<Node>::append(class Node* const):146 0x0000000000401788] append(class Node* const): pushq %rbp
(idb) $pc/1i
void List<Node>::append(class Node* const): src/x_list.cxx
*[line 146, 0x0000000000401788] append(class Node* const): pushq %rbp
Stepping through lines of source code:
(idb) list
172
173 if (i == 1) cout << "The list is empty ";
174 cout << endl << endl;
175 }
176
177
178 // The driver for this test
179 //
180 main()
181 {
182 List<Node> nodeList;
183
184 // add entries to list
185 //
186 IntNode* newNode = new IntNode(1);
187 nodeList.append(newNode); {static int somethingToReturnTo; somethingToReturnTo++; }
188
189 CompoundNode* cNode = new CompoundNode(12.345, 2);
190 nodeList.append(cNode); {static int somethingToReturnTo; somethingToReturnTo++; }
191
(idb) next
186 IntNode* newNode = new IntNode(1);
(idb) next 3
190 nodeList.append(cNode); {static int somethingToReturnTo; somethingToReturnTo++; }
(idb) step
List<Node>::append (node=(class Node *) 0x503030) at src/x_list.cxx:148
148 if (!_firstNode)
(idb) list -2,+6
146 {
147
148 if (!_firstNode)
149 _firstNode = node;
150 else {
151 Node* currentNode = _firstNode;
(idb) step
151 Node* currentNode = _firstNode;
(idb) list -2,+5
149 _firstNode = node;
150 else {
151 Node* currentNode = _firstNode;
152 while (currentNode->getNextNode())
153 currentNode = currentNode->getNextNode();
(idb) finish
main () at src/x_list.cxx:190
190 nodeList.append(cNode); {static int somethingToReturnTo; somethingToReturnTo++; }
(idb) next 2
193 nodeList.append(cNode1); {static int somethingToReturnTo; somethingToReturnTo++; }
Stepping at the instruction level:
(idb) x /2i $pc
0x401788 <append>: pushq %rbp
0x401789 <append+1>: movq %rsp, %rbp
(idb) nexti
146 {
(idb) x /1i $pc
0x401789 <append+1>: movq %rsp, %rbp
(idb) run
Program exited
Starting program: /site/spt/usr8/brbrett/project_anmod/test/idb/Examples/exp/x86_64-Linux-development/debuggable/x_list
Breakpoint 3, main () at src/x_list.cxx:193
193 nodeList.append(cNode1); {static int somethingToReturnTo; somethingToReturnTo++; }
(idb) x /2i $pc
0x400ed0 <main+760>: call 0x401788 <append>
0x400ed5 <main+765>: addl $0x1, -4293911744(%rip)
(idb) stepi
List<Node>::append (node=(class Node *) 0x0) at src/x_list.cxx:146
146 {
(idb) x /1i $pc
0x401788 <append>: pushq %rbp
Often when you move the process forward, you accidentally go too far. For example, you may step over a call that you should have stepped into.
In a program that does not use multiple threads, you can use snapshots to save your state before you step over the call. Then clone that snapshot to position another process just before the call so you can step into it.
The following example shows the stages of a snapshot being used in this way:
The first stage is to build the program and start debugging.
The next stage is to stop the process just before the call and take a
snapshot. You can
see you are just before the call because the right bracket (>) to the left of
the source list shows the line about to be executed.
(idb) next 2
stopped at [int main(void):187 0x1200024b8]
187 nodeList.append(newNode);
(idb) list $curline - 10:20
177
178 // The driver for this test
179 //
180 main()
181 {
182 List<Node> nodeList;
183
184 // add entries to list
185 //
186 IntNode* newNode = new IntNode(1);
> 187 nodeList.append(newNode);
188
189 CompoundNode* cNode = new CompoundNode(12.345, 2);
190 nodeList.append(cNode);
191
192 CompoundNode* cNode1 = new CompoundNode(3.1415, 7);
193 nodeList.append(cNode1);
194
195 nodeList.append(new IntNode(3));
196
(idb) save snapshot
# 1 saved at 08:41:46 (PID: 1012).
stopped at [int main(void):187 0x1200024b8]
187 nodeList.append(newNode);
You now step over the call. The
execution is now after the call, shown by the right bracket (>) being on the
following source line.
(idb) next
stopped at [int main(void):189 0x1200024d0]
189 CompoundNode* cNode = new CompoundNode(12.345, 2);
(idb) list $curline - 10:20
179 //
180 main()
181 {
182 List<Node> nodeList;
183
184 // add entries to list
185 //
186 IntNode* newNode = new IntNode(1);
187 nodeList.append(newNode);
188
> 189 CompoundNode* cNode = new CompoundNode(12.345, 2);
190 nodeList.append(cNode);
191
192 CompoundNode* cNode1 = new CompoundNode(3.1415, 7);
193 nodeList.append(cNode1);
194
195 nodeList.append(new IntNode(3));
196
197 IntNode* newNode2 = new IntNode(4);
198 nodeList.append(newNode2);
Oh, how you wish you hadn't done that! No problem, just clone that snapshot you made.
(idb) clone snapshot
Process has exited
Process 1009 cloned from Snapshot 1.
# 1 saved at 08:41:46 (PID: 1012).
stopped at [int main(void):187 0x1200024b8]
187 nodeList.append(newNode);
Now you are in a new process before the call is executed.
(idb) list $curline - 10:20
177
178 // The driver for this test
179 //
180 main()
181 {
182 List<Node> nodeList;
183
184 // add entries to list
185 //
186 IntNode* newNode = new IntNode(1);
> 187 nodeList.append(newNode);
188
189 CompoundNode* cNode = new CompoundNode(12.345, 2);
190 nodeList.append(cNode);
191
192 CompoundNode* cNode1 = new CompoundNode(3.1415, 7);
193 nodeList.append(cNode1);
194
195 nodeList.append(new IntNode(3));
196
Note: fork() was used by the debugger both to create the
snapshot and to clone it.
Part II provides most of the information needed to make expert use of the debugger.
Some additional details have been moved to Part III: Advanced Topics so they do not hinder the reading of this section.
To facilitate debugging, you can prepare your source code and the compiler and linker environment.
You do not need to make changes to the source code to debug the program. However, you can do the following to make debugging easier:
Debugging information is put into
.o
files by compilers. The level and format
of information is controlled by compiler options.
Use the -g option
with the Intel® Compiler, for example:
% icc -g hello.c ... % icpc -g hello.cpp ...
With the GNU Compiler Collection (GCC,
versions earlier than 3.x),
use the -gdwarf-2 option:
% gcc -gdwarf-2 hello.c ... % g++ -gdwarf-2 hello.cpp ...
See your compiler's reference page for more details.
The debugging information is propagated into the
a.out (executable)
or
.so (shared library)
by the ld command.
It is removed by the strip command. If you strip your programs,
keep the unstripped version to use with the debugger.
The debugging information can cause
.o
files to be very large,
causing long link times, but even so it can also be incomplete.
If you are debugging optimized code, refer to the appropriate compiler
documentation for information about
various -g switches
and their relationship to optimization.
You can start the debugger in the following ways:
This chapter also discusses the following topics:
When you invoke the debugger from a shell, you can bring a program or core file under debugger control, or you can attach to a running process.
The following is the
shell
syntax to invoke the debugger using the
idb command:
idb [idb_options ] [ executable_file [ core_file ] ]
Note that the set of recognized options depends on the mode. For example, -V option is valid in DBX
mode, but not in GDB mode.
idb_options:
[ -c file ]
[ -cd directory ]
[ -command file ]
[ -dbx ]
[ -echo ]
[ -emacs ]
[ -fullname ]
[ -gdb [ gdb_options ] ]
[ -gui ]
[ -i file ]
[ -I dir ]
[ -interactive ]
[ -maxruntime minutes ]
[ -nosharedobjs ]
[ -parallel launcher launcher_args ]
[ -pid process_id ]
[ -prompt string ]
[ -quiet ]
[ -tty terminal_device ]
[ -ui name ]
[ -version ]
[ -x file ]
gdb_option
: -cd dir
| -command file
| -d[irectory] dir
| -f[ullname]
| -gdb [ gdb_options ]
| -help
| -interpreter name
| -nowindows
| -nw
| -p[id] pid
| -q[uiet]
| -silent
| -tty device
| -version
| -ui name
| -x file
The following two tables describe the idb command
options and parameters. First shown are the Default mode options:
| Options and Parameters | Mode | Description |
|---|---|---|
-c file
|
Default |
Specifies an initialization command file. The default initialization file is
.dbxinit.
During startup, the debugger searches for this file in
the current directory. If it is not there, the debugger searches
your home directory. This file is processed after the target process has been
loaded or attached to.
|
-cd dir
|
Default | Specifies a new working directory. |
-echo
|
Default | Causes the debugger to print the prompt when running in a non-interactive session. |
-gdb
|
Default | Causes the debugger to use GDB compatibility mode and the gdb_options options set. |
-gui
|
Default | Activates the debugger's graphical user interface (GUI). |
-emacs-fullname
|
Default | Output file and line number markers for emacs. |
-help
|
Default | Print help message and exit. |
-i file
|
Default |
Specifies a pre-initialization command file. The default pre-initialization
file is
.idbrc.
The debugger
searches for this file during startup, first in the current
directory and then in your home directory. This file is processed before
the debugger has connected to the application being debugged, so that commands
such as set $stoponattach = 1 will have taken effect when the
connection is made.
|
-I dir
|
Default |
Specifies the directory containing the source code for the target
program, in a manner similar to the use command. Use multiple
-I options to specify more than one directory.
The debugger searches directories in the order in which they were
specified on the command line.
|
-interactive
|
Default |
Causes the debugger to act as though stdin is isatty(),
regardless of whether or not it is. This flag is sometimes useful when using
rsh to run the debugger. Currently, the only effect is to cause
the debugger to output the prompt to stdout when it is ready for
the next line of input.
|
-maxruntime minutes
|
Default | Specifies the maximum allowable runtime in minutes for the debugging session. |
-nosharedobjs
|
Default |
Prevents the reading of symbol table information for any
shared objects
loaded when the process executes. Later in the debug session, you can
enter the readsharedobj command to read the
symbol table information for a specified
object.
|
-parallel launcher launcher_args
|
Default | Starts a debugging session on a parallel application created by launcher with arguments launcher_args. See Chapter 19 for details on using the parallel debugging feature. |
-pid pid
|
Default | Specifies the process ID of the process to be debugged. |
-prompt string
|
Default |
Specifies a debugger prompt. If the prompt
argument contains spaces or special
characters, enclose the argument in quotes ( % idb -prompt ">> " >> quit Default Mode
You can also change the prompt by setting the
(idb) set $prompt = "newPrompt>> " newPrompt>> GDB Mode
Use (idb) set prompt (gdb mode) (gdb mode) show prompt Intel IDB's prompt is "(gdb mode) ". (gdb mode) Note: There is a space at the end of the first line of the example above. If the space is missed, the result will be as follows: (idb) set prompt (gdb mode) (gdb mode)show prompt Intel IDB's prompt is "(gdb mode)". (gdb mode) |
-quiet
|
Default | Causes the debugger to start but not to print sign-on message. |
-tty terminal_device
|
Default | Specifies the input/output tty device for the user program. |
executable_file
|
ALL |
Specifies the program executable file. |
core_file
|
ALL |
Specifies the core file. |
The following table shows the GDB mode options:
| Options and Parameters | Mode | Description |
|---|---|---|
-cd dir
|
GDB | Specifies a new working directory. |
-command file |
GDB |
Specifies an initialization command file. The default initialization file is
.dbxinit.
During startup, the debugger searches for this file in
the current directory. If it is not there, the debugger searches
your home directory. This file is processed after the target process has been
loaded or attached.
|
-dbx
|
GDB | Causes the debugger to use the idb_options options set (default). |
-directory dir
|
GDB |
|
-fullname
|
GDB | |
-help
|
GDB | Print help message and exit. |
-interpreter name-ui name
|
GDB |
|
-nowindows-nw
|
GDB | Do not use a window interface. |
-pid pid
|
GDB |
See DBX mode option -pid.
|
-quiet-silent
|
GDB | Do not print copyright message. |
-tty device
|
GDB | Use device for input/output by the program being debugged. |
-version
|
GDB | Print version information and exit. |
Note: Options can be prefixed by a dash (-) or double dash (--)
.
Option names may be abbreviated as long as the abbreviations are unique.
An option and its argument are separated with one or more spaces or equal sign (=).
For example, to invoke the debugger on an executable file named
a.out:
% idb a.out
To invoke the debugger on a core file:
% idb a.out core
To invoke the debugger and attach to a running process when you do not know what file it is executing:
% idb -pid 8492
You can control your debugger process entirely through the Emacs Grand Unified Debugger (GUD) buffer mode, which is a variant of shell mode. All the debugger commands are available, and you can use the shell mode history commands to repeat them.
The debugger supports:
The information in the following sections assumes you are familiar with Emacs and are using the Emacs notation for naming keys and key sequences.
For each Emacs session, before you can invoke the debugger, you must load the Intel Debugger-specific Emacs LISP code, as follows:
M-x load-file
At the Load file: prompt, type the path to the Intel Debugger-specific
Emacs LISP file, which is located in the Intel IDB installation directory. For
example:
/opt/intel_idb/bin/idb.el
You can also place a load-file call in your
Emacs initialization file (~/.emacs). For example:
(load-file "/opt/intel_idb/bin/idb.el")
To start the debugger with Emacs, type:
M-x idb
The following invocation line displays:
Run the debugger (like this): idb
Edit the invocation line by typing the target program and pressing Return. Emacs remembers the invocation. To debug the same program again, you need only press Return.
Emacs displays the GUD buffer and runs the debugger within it; the debugger
starts and displays its (idb) prompt, indicating readiness.
The GUD buffer saves all of the commands you type and the program output for
you to edit. In general, interact with the debugger in the GUD buffer as you
would with a debugger started from a shell.
One of the benefits of running the debugger from within Emacs is a closer correlation between program execution and source. When your program stops (for example, at a breakpoint), Emacs displays the source of your program in a
GNU* DDD* is a graphical front-end for command-line debuggers that can be used with Intel IDB.
Specify --ladebug and --debugger idb options in the shell command line,
for example:
$ ddd --ladebug --debugger idb a.out
If idb is not accessible trough PATH environment variable,
specify path to the debugger, absolute or relative, for example:
$ ddd --ladebug --debugger /opt/intel_idb/bin/idb a.out
Specify --debugger "idb -gdb" options in the shell command line,
for example:
$ ddd --debugger "idb -gdb" a.out
If idb is not accessible trough PATH environment variable,
specify path to the debugger, absolute or relative, for example:
$ ddd --debugger "/opt/intel_idb/bin/idb -gdb" a.out
To exit the debugger, use the quit command:
quit_command : quit
Alternatively, you can type q or exit, which are pre-defined
aliases for quit.
To exit the debugger, use quit or the q command.
Optionally, you can specify debugger exit status. Example:
quit_command
: quit [ exit_status ]
| q [ exit_status ]
exit_status
: expression
To access the online help about debugger commands, use the
help
command.
help_command : help [ topic ]
Enter help to see a list of help topics. Enter help
command to see a list of debugger c