📄 idb_release_notes.html
字号:
command history recorded in the history file (which defaults to
<i>./.gdb_history</i>)
<p>
There are several options for managing initialization files:
<ol>
<li><code>idb -gdb <b>-x</b> <command file></code><br><br>
This is similar to <i>-c</i> and <i>-i</i> in DBX mode
(remember that <i>-i</i> replaces <i>.idbrc</i>, <i>-c</i> replaces
<i>.dbxinit</i>).
This option however, processes command files passed with <i>-x</i>
in addition to <i>.gdbinit</i>. <i>-x</i> can be passed to
the debugger more than one time on the command line.<br><br>
<li><code>idb -gdb <b>-n[x]</b></code><br><br>
<i>-n</i> and <i>-nx</i> cause the debugger to <i>skip</i> reading
<i>.gdbinit</i>. However, if command files are also passed using
<i>-x</i>, they are read and executed.
</ol>
<h4><a name="HISTFILES_GDB_"></a>
Command History</h4>
<p>
The
In GDB mode, the debugger will read <i>.gdb_history</i> by default. You
can also use the following commands to control the behavior of
command history:
<ul>
<li><b>Renaming the history file</b><br><br>
There are 2 ways to rename the history file, which will override the
default (.gdb_history).
<ol>
<li><code><b>
(idb) set history filename <name>
</code></b><br>
<li>Set the environment variable <b>GDBHISTFILE</b> to the filename
of the history file you want to use. This can be overridden during
the debug session by using the
<i>set history file <name></i> command.
</ol>
</li>
<li><b>Turning history recording on & off</b><br><br>
<b><code>(idb) set history save [on|off]</code></b><br>
</li><br>
<li><b>Configuring the history size</b><br><br>
There are 2 ways to configure the size of the history buffer (the number
of items retained):
<ol>
<li><b><code>
(idb) set history size <number>
</code></b><br>
<li>Set the environment variable <b>HISTSIZE</b> to the size you
want.
</ol>
<br>
If neither of these choices are used, the default value is 256.
</li>
</ul>
<h4><a name=CMDLINE_OPTS_>
GDB command line options</a></h4>
<p>
The following command line options are now supported:
<br><br>
<b>--args</b>
<p>
<ul><code><small>
idb [-gdb] [idb options] <b>[-]-args</b>
<exec_file [args for exec_file]
</small></code><br><br>
The first argument after this option must be an executable
file. Arguments follow the executable file are command line
arguments to the executable. When <i>--args</i> is
encountered, remaining arguments are treated as if they should
be sent to the executable.
The executable file passed before encountering <b>--args</b> is
ignored. After the debugger loads the executable, you can use <b>show
args</b> to see all arguments that will be passed to the executable.
<br><br>This option is available in both GDB and DBX mode.
</ul>
<p><b>--batch</b>
<p>
<ul><code><small>
idb [-gdb] [idb options] <b>[-]-batch</b>
[-x <command file> ...]
</small></code><br><br>
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 <i>-x</i> (assuming <i>-n</i> is not passed. ).
If an error occurs in executing commands from command files or
initialization files, the debugger will exit with a nonzero status.
<br><br>This option is available in both GDB and DBX mode.
</ul>
<p><b>--core</b>
<p>
<ul><code><small>
idb -gdb <b>-[-]c[ore]</b>[=|<space>]<core_file>
</small></code><br><br>
Debug a core file. You don't need to tell the debugger the name of
the executable. The meaning of <i>-c</i> 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:
<br><br>
<ul><code><small>
idb -c <command_file > -gdb -c <core_file>
</small></code></ul>
<br></ul>
<p><b>--exec</b>
<p>
<ul><code><small>
idb -gdb <b>-[-]e[xec]</b>[=|<space>]<exec_file>
</small></code><br><br>
Specify the executable to debug.
<br></ul>
<p><b>--pid</b>
<p>
<ul><code><small>
idb [-gdb] <b>-[-]p[id]</b> <process-id>
</small></code><br><br>
Attach to process, given the process-id. There is no need to
specify the executable or core file.
<br><br>This option is available in both GDB and DBX mode.
</ul>
<h4><a name=INFO_></a>
info variables, info types, info functions</h4>
<p>
<code><small>
info var[iables] [<string>|REGEXP]
</small></code><br><br>
<i><string></i> is a simple search string; <i>REGEXP</i> is a regular
expression. The resulting list is the list of global and static
variables in the debuggee that match <i><string></i> or <i>REGEXP</i>.
<br><br>
<code><small>
info fu[nctions] [<string>|REGEXP]
</small></code><br><br>
<i><string></i> is a simple search string; <i>REGEXP</i> is a regular
expression. The resulting list is the list of global and static
functions in the debuggee that match <i><string></i> or <i>REGEXP</i>.
<br><br>
<code><small>
info ty[pes] [<string>|REGEXP]
</small></code><br><br>
<i><string></i> is a simple search string; <i>REGEXP</i> is a regular
expression. The resulting list is the list of types used in the
debuggee that matches <i><string></i> or <i>REGEXP</i>.
<h4><a name=COMPLETE_></a>
Command, filename and variable completion</h4>
<p>
Completion of commands, filenames, and variables is supported. Simply
start typing a command, filename or variable and press the <i>tab</i>
key. If there is more than one alternative, the debugger sounds a
bell; pressing <i>tab</i> again causes the debuger to list the
alternatives.
<br><br>
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.
<br><br>
The debugger doesn't automatically detect cases where quotes are needed
(as GDB does).
<h4><a name=UDC_></a>
Support for user-defined commands</h4>
<p>
The debugger now supports user defined commands. These commands support
<i>if</i>, <i>while</i>, <i>loop_break</i> and <i>loop_continue</i>
in their bodies. User-defined commands can have up to 10 arguments
separated by whitespace. Argument names are
<code>$arg0</code>, <code>$arg1</code>, <code>$arg2</code>,..., <code>$arg9</code>.
The number of arguments is held in <code>$argc</code>.
</p><p>
The debugger supports the following commands to control user-defined
commands:
<ul>
<li>
<code><b>(idb) set max-user-call-depth <depth></code></b><br>
Sets max level of recursion for user defined commands.
The default value is 1024.<br><br>
<li>
<code><b>(idb) show max-user-call-depth</code></b><br>
Shows current available level of recursion.
</ul>
<p>
The debugger doesn't yet support the <i>document</i>,
<i>help user-defined</i>, <i>dont-repeat</i> commands or user-defined hooks.
</p>
<h3><a name=PENDING_BPT_>
Support for Pending Breakpoints</a></h3>
<p>
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 <i>pending</i> 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:
<ul>
<li>
<code><b>(idb) set breakpoint pending auto</code></b><br>
This is the default value. If the debugger cannot resolve
breakpoint location, the user is asked whether to create a
pending breakpoint.<br><br>
<li>
<code><b>(idb) set breakpoint pending on</code></b><br>
Always set pending breakpoints on unresolved locations.<br><br>
<li>
<code><b>(idb) set breakpoint pending off</code></b><br>
Never set pending breakpoint on unresolved locations.<br><br>
<li>
<code><b>(idb) show breakpoint pending</code></b><br>
Show the behavior of the pending breakpoint support.<br><br>
</ul>
<p>
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.
<br><br>
This feature is supported in DBX and GDB user interfaces.
</p>
<h3> <a name=OpenMP_Support_>
OpenMP Support</a></h3>
<p>
The debugger is capable of providing information on OpenMP
locks, teams, and threads when debugging an OpenMP application.
</p>
<p>
To enable this support, the debugger requires access to
the shared library <code>libomp_db.so</code>, which by default
is in the <code>lib</code> directory in your compiler installation.
</p>
<p>
The debugger automatically enables the OpenMP support when
it detects that the debuggee is an OpenMP program. To switch
off the support, do
</p>
<p><code>
(idb) set $threadlevel="native"
</code> </p>
<p>
To switch it back on, do
</p>
<p><code>
(idb) set $threadlevel="openmp"
</code> </p>
<p>
When the OpenMP support is on, you can use the following commands
to inspect the states of the OpenMP objects in your program:
<ol>
<li><b><code>show lock [<i>lock id, ...</i> ]</code></b>
<p>
This command displays the state of the locks that are
specified, or the state of all the locks if none is
specified. E.g.:
<p><pre><code>
(idb) show lock nlk
Id Type State Holder Id Level Waiters
0x6000000000009e00 nested held 1 1 3 threads: 2, 3, 4
</code></pre></p>
<p>In this example, the lock <code>nlk</code> 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 "<code>show thread</code>".
</p>
</li>
<li><b><code>show openmp thread tree</code></b>
<p>
This command displays the threads in the process
in a tree format to illustrate the team master/member
relation between threads. E.g.:
<p><pre><code>
(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
</code></pre></p>
<p>The numbers in square brackets are the OpenMP
thread IDs in their respective team.
</p>
</li>
<li><b><code>show team [<i>team id, ...</i>]</code></b>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -