You cannot select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
527 lines
26 KiB
HTML
527 lines
26 KiB
HTML
4 years ago
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
|
||
|
|
<html>
|
||
|
|
<!-- Copyright (C) 1988-2019 Free Software Foundation, Inc.
|
||
|
|
|
||
|
|
Permission is granted to copy, distribute and/or modify this document
|
||
|
|
under the terms of the GNU Free Documentation License, Version 1.3 or
|
||
|
|
any later version published by the Free Software Foundation; with the
|
||
|
|
Invariant Sections being "Free Software" and "Free Software Needs
|
||
|
|
Free Documentation", with the Front-Cover Texts being "A GNU Manual,"
|
||
|
|
and with the Back-Cover Texts as in (a) below.
|
||
|
|
|
||
|
|
(a) The FSF's Back-Cover Text is: "You are free to copy and modify
|
||
|
|
this GNU Manual. Buying copies from GNU Press supports the FSF in
|
||
|
|
developing GNU and promoting software freedom." -->
|
||
|
|
<!-- Created by GNU Texinfo 6.4, http://www.gnu.org/software/texinfo/ -->
|
||
|
|
<head>
|
||
|
|
<title>Set Breaks (Debugging with GDB)</title>
|
||
|
|
|
||
|
|
<meta name="description" content="Set Breaks (Debugging with GDB)">
|
||
|
|
<meta name="keywords" content="Set Breaks (Debugging with GDB)">
|
||
|
|
<meta name="resource-type" content="document">
|
||
|
|
<meta name="distribution" content="global">
|
||
|
|
<meta name="Generator" content="makeinfo">
|
||
|
|
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
|
||
|
|
<link href="index.html#Top" rel="start" title="Top">
|
||
|
|
<link href="Concept-Index.html#Concept-Index" rel="index" title="Concept Index">
|
||
|
|
<link href="index.html#SEC_Contents" rel="contents" title="Table of Contents">
|
||
|
|
<link href="Breakpoints.html#Breakpoints" rel="up" title="Breakpoints">
|
||
|
|
<link href="Set-Watchpoints.html#Set-Watchpoints" rel="next" title="Set Watchpoints">
|
||
|
|
<link href="Breakpoints.html#Breakpoints" rel="prev" title="Breakpoints">
|
||
|
|
<style type="text/css">
|
||
|
|
<!--
|
||
|
|
a.summary-letter {text-decoration: none}
|
||
|
|
blockquote.indentedblock {margin-right: 0em}
|
||
|
|
blockquote.smallindentedblock {margin-right: 0em; font-size: smaller}
|
||
|
|
blockquote.smallquotation {font-size: smaller}
|
||
|
|
div.display {margin-left: 3.2em}
|
||
|
|
div.example {margin-left: 3.2em}
|
||
|
|
div.lisp {margin-left: 3.2em}
|
||
|
|
div.smalldisplay {margin-left: 3.2em}
|
||
|
|
div.smallexample {margin-left: 3.2em}
|
||
|
|
div.smalllisp {margin-left: 3.2em}
|
||
|
|
kbd {font-style: oblique}
|
||
|
|
pre.display {font-family: inherit}
|
||
|
|
pre.format {font-family: inherit}
|
||
|
|
pre.menu-comment {font-family: serif}
|
||
|
|
pre.menu-preformatted {font-family: serif}
|
||
|
|
pre.smalldisplay {font-family: inherit; font-size: smaller}
|
||
|
|
pre.smallexample {font-size: smaller}
|
||
|
|
pre.smallformat {font-family: inherit; font-size: smaller}
|
||
|
|
pre.smalllisp {font-size: smaller}
|
||
|
|
span.nolinebreak {white-space: nowrap}
|
||
|
|
span.roman {font-family: initial; font-weight: normal}
|
||
|
|
span.sansserif {font-family: sans-serif; font-weight: normal}
|
||
|
|
ul.no-bullet {list-style: none}
|
||
|
|
-->
|
||
|
|
</style>
|
||
|
|
|
||
|
|
|
||
|
|
</head>
|
||
|
|
|
||
|
|
<body lang="en">
|
||
|
|
<a name="Set-Breaks"></a>
|
||
|
|
<div class="header">
|
||
|
|
<p>
|
||
|
|
Next: <a href="Set-Watchpoints.html#Set-Watchpoints" accesskey="n" rel="next">Set Watchpoints</a>, Up: <a href="Breakpoints.html#Breakpoints" accesskey="u" rel="up">Breakpoints</a> [<a href="index.html#SEC_Contents" title="Table of contents" rel="contents">Contents</a>][<a href="Concept-Index.html#Concept-Index" title="Index" rel="index">Index</a>]</p>
|
||
|
|
</div>
|
||
|
|
<hr>
|
||
|
|
<a name="Setting-Breakpoints"></a>
|
||
|
|
<h4 class="subsection">5.1.1 Setting Breakpoints</h4>
|
||
|
|
|
||
|
|
|
||
|
|
<a name="index-break"></a>
|
||
|
|
<a name="index-b-_0028break_0029"></a>
|
||
|
|
<a name="index-_0024bpnum_002c-convenience-variable"></a>
|
||
|
|
<a name="index-latest-breakpoint"></a>
|
||
|
|
<p>Breakpoints are set with the <code>break</code> command (abbreviated
|
||
|
|
<code>b</code>). The debugger convenience variable ‘<samp>$bpnum</samp>’ records the
|
||
|
|
number of the breakpoint you’ve set most recently; see <a href="Convenience-Vars.html#Convenience-Vars">Convenience Variables</a>, for a discussion of what you can do with
|
||
|
|
convenience variables.
|
||
|
|
</p>
|
||
|
|
<dl compact="compact">
|
||
|
|
<dt><code>break <var>location</var></code></dt>
|
||
|
|
<dd><p>Set a breakpoint at the given <var>location</var>, which can specify a
|
||
|
|
function name, a line number, or an address of an instruction.
|
||
|
|
(See <a href="Specify-Location.html#Specify-Location">Specify Location</a>, for a list of all the possible ways to
|
||
|
|
specify a <var>location</var>.) The breakpoint will stop your program just
|
||
|
|
before it executes any of the code in the specified <var>location</var>.
|
||
|
|
</p>
|
||
|
|
<p>When using source languages that permit overloading of symbols, such as
|
||
|
|
C<tt>++</tt>, a function name may refer to more than one possible place to break.
|
||
|
|
See <a href="Ambiguous-Expressions.html#Ambiguous-Expressions">Ambiguous Expressions</a>, for a discussion of
|
||
|
|
that situation.
|
||
|
|
</p>
|
||
|
|
<p>It is also possible to insert a breakpoint that will stop the program
|
||
|
|
only if a specific thread (see <a href="Thread_002dSpecific-Breakpoints.html#Thread_002dSpecific-Breakpoints">Thread-Specific Breakpoints</a>)
|
||
|
|
or a specific task (see <a href="Ada-Tasks.html#Ada-Tasks">Ada Tasks</a>) hits that breakpoint.
|
||
|
|
</p>
|
||
|
|
</dd>
|
||
|
|
<dt><code>break</code></dt>
|
||
|
|
<dd><p>When called without any arguments, <code>break</code> sets a breakpoint at
|
||
|
|
the next instruction to be executed in the selected stack frame
|
||
|
|
(see <a href="Stack.html#Stack">Examining the Stack</a>). In any selected frame but the
|
||
|
|
innermost, this makes your program stop as soon as control
|
||
|
|
returns to that frame. This is similar to the effect of a
|
||
|
|
<code>finish</code> command in the frame inside the selected frame—except
|
||
|
|
that <code>finish</code> does not leave an active breakpoint. If you use
|
||
|
|
<code>break</code> without an argument in the innermost frame, <small>GDB</small> stops
|
||
|
|
the next time it reaches the current location; this may be useful
|
||
|
|
inside loops.
|
||
|
|
</p>
|
||
|
|
<p><small>GDB</small> normally ignores breakpoints when it resumes execution, until at
|
||
|
|
least one instruction has been executed. If it did not do this, you
|
||
|
|
would be unable to proceed past a breakpoint without first disabling the
|
||
|
|
breakpoint. This rule applies whether or not the breakpoint already
|
||
|
|
existed when your program stopped.
|
||
|
|
</p>
|
||
|
|
</dd>
|
||
|
|
<dt><code>break … if <var>cond</var></code></dt>
|
||
|
|
<dd><p>Set a breakpoint with condition <var>cond</var>; evaluate the expression
|
||
|
|
<var>cond</var> each time the breakpoint is reached, and stop only if the
|
||
|
|
value is nonzero—that is, if <var>cond</var> evaluates as true.
|
||
|
|
‘<samp>…</samp>’ stands for one of the possible arguments described
|
||
|
|
above (or no argument) specifying where to break. See <a href="Conditions.html#Conditions">Break Conditions</a>, for more information on breakpoint conditions.
|
||
|
|
</p>
|
||
|
|
<a name="index-tbreak"></a>
|
||
|
|
</dd>
|
||
|
|
<dt><code>tbreak <var>args</var></code></dt>
|
||
|
|
<dd><p>Set a breakpoint enabled only for one stop. The <var>args</var> are the
|
||
|
|
same as for the <code>break</code> command, and the breakpoint is set in the same
|
||
|
|
way, but the breakpoint is automatically deleted after the first time your
|
||
|
|
program stops there. See <a href="Disabling.html#Disabling">Disabling Breakpoints</a>.
|
||
|
|
</p>
|
||
|
|
<a name="index-hbreak"></a>
|
||
|
|
<a name="index-hardware-breakpoints"></a>
|
||
|
|
</dd>
|
||
|
|
<dt><code>hbreak <var>args</var></code></dt>
|
||
|
|
<dd><p>Set a hardware-assisted breakpoint. The <var>args</var> are the same as for the
|
||
|
|
<code>break</code> command and the breakpoint is set in the same way, but the
|
||
|
|
breakpoint requires hardware support and some target hardware may not
|
||
|
|
have this support. The main purpose of this is EPROM/ROM code
|
||
|
|
debugging, so you can set a breakpoint at an instruction without
|
||
|
|
changing the instruction. This can be used with the new trap-generation
|
||
|
|
provided by SPARClite DSU and most x86-based targets. These targets
|
||
|
|
will generate traps when a program accesses some data or instruction
|
||
|
|
address that is assigned to the debug registers. However the hardware
|
||
|
|
breakpoint registers can take a limited number of breakpoints. For
|
||
|
|
example, on the DSU, only two data breakpoints can be set at a time, and
|
||
|
|
<small>GDB</small> will reject this command if more than two are used. Delete
|
||
|
|
or disable unused hardware breakpoints before setting new ones
|
||
|
|
(see <a href="Disabling.html#Disabling">Disabling Breakpoints</a>).
|
||
|
|
See <a href="Conditions.html#Conditions">Break Conditions</a>.
|
||
|
|
For remote targets, you can restrict the number of hardware
|
||
|
|
breakpoints <small>GDB</small> will use, see <a href="Remote-Configuration.html#set-remote-hardware_002dbreakpoint_002dlimit">set remote hardware-breakpoint-limit</a>.
|
||
|
|
</p>
|
||
|
|
<a name="index-thbreak"></a>
|
||
|
|
</dd>
|
||
|
|
<dt><code>thbreak <var>args</var></code></dt>
|
||
|
|
<dd><p>Set a hardware-assisted breakpoint enabled only for one stop. The <var>args</var>
|
||
|
|
are the same as for the <code>hbreak</code> command and the breakpoint is set in
|
||
|
|
the same way. However, like the <code>tbreak</code> command,
|
||
|
|
the breakpoint is automatically deleted after the
|
||
|
|
first time your program stops there. Also, like the <code>hbreak</code>
|
||
|
|
command, the breakpoint requires hardware support and some target hardware
|
||
|
|
may not have this support. See <a href="Disabling.html#Disabling">Disabling Breakpoints</a>.
|
||
|
|
See also <a href="Conditions.html#Conditions">Break Conditions</a>.
|
||
|
|
</p>
|
||
|
|
<a name="index-rbreak"></a>
|
||
|
|
<a name="index-regular-expression"></a>
|
||
|
|
<a name="index-breakpoints-at-functions-matching-a-regexp"></a>
|
||
|
|
<a name="index-set-breakpoints-in-many-functions"></a>
|
||
|
|
</dd>
|
||
|
|
<dt><code>rbreak <var>regex</var></code></dt>
|
||
|
|
<dd><p>Set breakpoints on all functions matching the regular expression
|
||
|
|
<var>regex</var>. This command sets an unconditional breakpoint on all
|
||
|
|
matches, printing a list of all breakpoints it set. Once these
|
||
|
|
breakpoints are set, they are treated just like the breakpoints set with
|
||
|
|
the <code>break</code> command. You can delete them, disable them, or make
|
||
|
|
them conditional the same way as any other breakpoint.
|
||
|
|
</p>
|
||
|
|
<p>In programs using different languages, <small>GDB</small> chooses the syntax
|
||
|
|
to print the list of all breakpoints it sets according to the
|
||
|
|
‘<samp>set language</samp>’ value: using ‘<samp>set language auto</samp>’
|
||
|
|
(see <a href="Automatically.html#Automatically">Set Language Automatically</a>) means to use the
|
||
|
|
language of the breakpoint’s function, other values mean to use
|
||
|
|
the manually specified language (see <a href="Manually.html#Manually">Set Language Manually</a>).
|
||
|
|
</p>
|
||
|
|
<p>The syntax of the regular expression is the standard one used with tools
|
||
|
|
like <samp>grep</samp>. Note that this is different from the syntax used by
|
||
|
|
shells, so for instance <code>foo*</code> matches all functions that include
|
||
|
|
an <code>fo</code> followed by zero or more <code>o</code>s. There is an implicit
|
||
|
|
<code>.*</code> leading and trailing the regular expression you supply, so to
|
||
|
|
match only functions that begin with <code>foo</code>, use <code>^foo</code>.
|
||
|
|
</p>
|
||
|
|
<a name="index-non_002dmember-C_002b_002b-functions_002c-set-breakpoint-in"></a>
|
||
|
|
<p>When debugging C<tt>++</tt> programs, <code>rbreak</code> is useful for setting
|
||
|
|
breakpoints on overloaded functions that are not members of any special
|
||
|
|
classes.
|
||
|
|
</p>
|
||
|
|
<a name="index-set-breakpoints-on-all-functions"></a>
|
||
|
|
<p>The <code>rbreak</code> command can be used to set breakpoints in
|
||
|
|
<strong>all</strong> the functions in a program, like this:
|
||
|
|
</p>
|
||
|
|
<div class="smallexample">
|
||
|
|
<pre class="smallexample">(gdb) rbreak .
|
||
|
|
</pre></div>
|
||
|
|
|
||
|
|
</dd>
|
||
|
|
<dt><code>rbreak <var>file</var>:<var>regex</var></code></dt>
|
||
|
|
<dd><p>If <code>rbreak</code> is called with a filename qualification, it limits
|
||
|
|
the search for functions matching the given regular expression to the
|
||
|
|
specified <var>file</var>. This can be used, for example, to set breakpoints on
|
||
|
|
every function in a given file:
|
||
|
|
</p>
|
||
|
|
<div class="smallexample">
|
||
|
|
<pre class="smallexample">(gdb) rbreak file.c:.
|
||
|
|
</pre></div>
|
||
|
|
|
||
|
|
<p>The colon separating the filename qualifier from the regex may
|
||
|
|
optionally be surrounded by spaces.
|
||
|
|
</p>
|
||
|
|
<a name="index-info-breakpoints"></a>
|
||
|
|
<a name="index-_0024_005f-and-info-breakpoints"></a>
|
||
|
|
</dd>
|
||
|
|
<dt><code>info breakpoints <span class="roman">[</span><var>list</var>…<span class="roman">]</span></code></dt>
|
||
|
|
<dt><code>info break <span class="roman">[</span><var>list</var>…<span class="roman">]</span></code></dt>
|
||
|
|
<dd><p>Print a table of all breakpoints, watchpoints, and catchpoints set and
|
||
|
|
not deleted. Optional argument <var>n</var> means print information only
|
||
|
|
about the specified breakpoint(s) (or watchpoint(s) or catchpoint(s)).
|
||
|
|
For each breakpoint, following columns are printed:
|
||
|
|
</p>
|
||
|
|
<dl compact="compact">
|
||
|
|
<dt><em>Breakpoint Numbers</em></dt>
|
||
|
|
<dt><em>Type</em></dt>
|
||
|
|
<dd><p>Breakpoint, watchpoint, or catchpoint.
|
||
|
|
</p></dd>
|
||
|
|
<dt><em>Disposition</em></dt>
|
||
|
|
<dd><p>Whether the breakpoint is marked to be disabled or deleted when hit.
|
||
|
|
</p></dd>
|
||
|
|
<dt><em>Enabled or Disabled</em></dt>
|
||
|
|
<dd><p>Enabled breakpoints are marked with ‘<samp>y</samp>’. ‘<samp>n</samp>’ marks breakpoints
|
||
|
|
that are not enabled.
|
||
|
|
</p></dd>
|
||
|
|
<dt><em>Address</em></dt>
|
||
|
|
<dd><p>Where the breakpoint is in your program, as a memory address. For a
|
||
|
|
pending breakpoint whose address is not yet known, this field will
|
||
|
|
contain ‘<samp><PENDING></samp>’. Such breakpoint won’t fire until a shared
|
||
|
|
library that has the symbol or line referred by breakpoint is loaded.
|
||
|
|
See below for details. A breakpoint with several locations will
|
||
|
|
have ‘<samp><MULTIPLE></samp>’ in this field—see below for details.
|
||
|
|
</p></dd>
|
||
|
|
<dt><em>What</em></dt>
|
||
|
|
<dd><p>Where the breakpoint is in the source for your program, as a file and
|
||
|
|
line number. For a pending breakpoint, the original string passed to
|
||
|
|
the breakpoint command will be listed as it cannot be resolved until
|
||
|
|
the appropriate shared library is loaded in the future.
|
||
|
|
</p></dd>
|
||
|
|
</dl>
|
||
|
|
|
||
|
|
<p>If a breakpoint is conditional, there are two evaluation modes: “host” and
|
||
|
|
“target”. If mode is “host”, breakpoint condition evaluation is done by
|
||
|
|
<small>GDB</small> on the host’s side. If it is “target”, then the condition
|
||
|
|
is evaluated by the target. The <code>info break</code> command shows
|
||
|
|
the condition on the line following the affected breakpoint, together with
|
||
|
|
its condition evaluation mode in between parentheses.
|
||
|
|
</p>
|
||
|
|
<p>Breakpoint commands, if any, are listed after that. A pending breakpoint is
|
||
|
|
allowed to have a condition specified for it. The condition is not parsed for
|
||
|
|
validity until a shared library is loaded that allows the pending
|
||
|
|
breakpoint to resolve to a valid location.
|
||
|
|
</p>
|
||
|
|
<p><code>info break</code> with a breakpoint
|
||
|
|
number <var>n</var> as argument lists only that breakpoint. The
|
||
|
|
convenience variable <code>$_</code> and the default examining-address for
|
||
|
|
the <code>x</code> command are set to the address of the last breakpoint
|
||
|
|
listed (see <a href="Memory.html#Memory">Examining Memory</a>).
|
||
|
|
</p>
|
||
|
|
<p><code>info break</code> displays a count of the number of times the breakpoint
|
||
|
|
has been hit. This is especially useful in conjunction with the
|
||
|
|
<code>ignore</code> command. You can ignore a large number of breakpoint
|
||
|
|
hits, look at the breakpoint info to see how many times the breakpoint
|
||
|
|
was hit, and then run again, ignoring one less than that number. This
|
||
|
|
will get you quickly to the last hit of that breakpoint.
|
||
|
|
</p>
|
||
|
|
<p>For a breakpoints with an enable count (xref) greater than 1,
|
||
|
|
<code>info break</code> also displays that count.
|
||
|
|
</p>
|
||
|
|
</dd>
|
||
|
|
</dl>
|
||
|
|
|
||
|
|
<p><small>GDB</small> allows you to set any number of breakpoints at the same place in
|
||
|
|
your program. There is nothing silly or meaningless about this. When
|
||
|
|
the breakpoints are conditional, this is even useful
|
||
|
|
(see <a href="Conditions.html#Conditions">Break Conditions</a>).
|
||
|
|
</p>
|
||
|
|
<a name="index-multiple-locations_002c-breakpoints"></a>
|
||
|
|
<a name="index-breakpoints_002c-multiple-locations"></a>
|
||
|
|
<p>It is possible that a breakpoint corresponds to several locations
|
||
|
|
in your program. Examples of this situation are:
|
||
|
|
</p>
|
||
|
|
<ul>
|
||
|
|
<li> Multiple functions in the program may have the same name.
|
||
|
|
|
||
|
|
</li><li> For a C<tt>++</tt> constructor, the <small>GCC</small> compiler generates several
|
||
|
|
instances of the function body, used in different cases.
|
||
|
|
|
||
|
|
</li><li> For a C<tt>++</tt> template function, a given line in the function can
|
||
|
|
correspond to any number of instantiations.
|
||
|
|
|
||
|
|
</li><li> For an inlined function, a given source line can correspond to
|
||
|
|
several places where that function is inlined.
|
||
|
|
</li></ul>
|
||
|
|
|
||
|
|
<p>In all those cases, <small>GDB</small> will insert a breakpoint at all
|
||
|
|
the relevant locations.
|
||
|
|
</p>
|
||
|
|
<p>A breakpoint with multiple locations is displayed in the breakpoint
|
||
|
|
table using several rows—one header row, followed by one row for
|
||
|
|
each breakpoint location. The header row has ‘<samp><MULTIPLE></samp>’ in the
|
||
|
|
address column. The rows for individual locations contain the actual
|
||
|
|
addresses for locations, and show the functions to which those
|
||
|
|
locations belong. The number column for a location is of the form
|
||
|
|
<var>breakpoint-number</var>.<var>location-number</var>.
|
||
|
|
</p>
|
||
|
|
<p>For example:
|
||
|
|
</p>
|
||
|
|
<div class="smallexample">
|
||
|
|
<pre class="smallexample">Num Type Disp Enb Address What
|
||
|
|
1 breakpoint keep y <MULTIPLE>
|
||
|
|
stop only if i==1
|
||
|
|
breakpoint already hit 1 time
|
||
|
|
1.1 y 0x080486a2 in void foo<int>() at t.cc:8
|
||
|
|
1.2 y 0x080486ca in void foo<double>() at t.cc:8
|
||
|
|
</pre></div>
|
||
|
|
|
||
|
|
<p>You cannot delete the individual locations from a breakpoint. However,
|
||
|
|
each location can be individually enabled or disabled by passing
|
||
|
|
<var>breakpoint-number</var>.<var>location-number</var> as argument to the
|
||
|
|
<code>enable</code> and <code>disable</code> commands. It’s also possible to
|
||
|
|
<code>enable</code> and <code>disable</code> a range of <var>location-number</var>
|
||
|
|
locations using a <var>breakpoint-number</var> and two <var>location-number</var>s,
|
||
|
|
in increasing order, separated by a hyphen, like
|
||
|
|
<kbd><var>breakpoint-number</var>.<var>location-number1</var>-<var>location-number2</var></kbd>,
|
||
|
|
in which case <small>GDB</small> acts on all the locations in the range (inclusive).
|
||
|
|
Disabling or enabling the parent breakpoint (see <a href="Disabling.html#Disabling">Disabling</a>) affects
|
||
|
|
all of the locations that belong to that breakpoint.
|
||
|
|
</p>
|
||
|
|
<a name="index-pending-breakpoints"></a>
|
||
|
|
<p>It’s quite common to have a breakpoint inside a shared library.
|
||
|
|
Shared libraries can be loaded and unloaded explicitly,
|
||
|
|
and possibly repeatedly, as the program is executed. To support
|
||
|
|
this use case, <small>GDB</small> updates breakpoint locations whenever
|
||
|
|
any shared library is loaded or unloaded. Typically, you would
|
||
|
|
set a breakpoint in a shared library at the beginning of your
|
||
|
|
debugging session, when the library is not loaded, and when the
|
||
|
|
symbols from the library are not available. When you try to set
|
||
|
|
breakpoint, <small>GDB</small> will ask you if you want to set
|
||
|
|
a so called <em>pending breakpoint</em>—breakpoint whose address
|
||
|
|
is not yet resolved.
|
||
|
|
</p>
|
||
|
|
<p>After the program is run, whenever a new shared library is loaded,
|
||
|
|
<small>GDB</small> reevaluates all the breakpoints. When a newly loaded
|
||
|
|
shared library contains the symbol or line referred to by some
|
||
|
|
pending breakpoint, that breakpoint is resolved and becomes an
|
||
|
|
ordinary breakpoint. When a library is unloaded, all breakpoints
|
||
|
|
that refer to its symbols or source lines become pending again.
|
||
|
|
</p>
|
||
|
|
<p>This logic works for breakpoints with multiple locations, too. For
|
||
|
|
example, if you have a breakpoint in a C<tt>++</tt> template function, and
|
||
|
|
a newly loaded shared library has an instantiation of that template,
|
||
|
|
a new location is added to the list of locations for the breakpoint.
|
||
|
|
</p>
|
||
|
|
<p>Except for having unresolved address, pending breakpoints do not
|
||
|
|
differ from regular breakpoints. You can set conditions or commands,
|
||
|
|
enable and disable them and perform other breakpoint operations.
|
||
|
|
</p>
|
||
|
|
<p><small>GDB</small> provides some additional commands for controlling what
|
||
|
|
happens when the ‘<samp>break</samp>’ command cannot resolve breakpoint
|
||
|
|
address specification to an address:
|
||
|
|
</p>
|
||
|
|
<a name="index-set-breakpoint-pending"></a>
|
||
|
|
<a name="index-show-breakpoint-pending"></a>
|
||
|
|
<dl compact="compact">
|
||
|
|
<dt><code>set breakpoint pending auto</code></dt>
|
||
|
|
<dd><p>This is the default behavior. When <small>GDB</small> cannot find the breakpoint
|
||
|
|
location, it queries you whether a pending breakpoint should be created.
|
||
|
|
</p>
|
||
|
|
</dd>
|
||
|
|
<dt><code>set breakpoint pending on</code></dt>
|
||
|
|
<dd><p>This indicates that an unrecognized breakpoint location should automatically
|
||
|
|
result in a pending breakpoint being created.
|
||
|
|
</p>
|
||
|
|
</dd>
|
||
|
|
<dt><code>set breakpoint pending off</code></dt>
|
||
|
|
<dd><p>This indicates that pending breakpoints are not to be created. Any
|
||
|
|
unrecognized breakpoint location results in an error. This setting does
|
||
|
|
not affect any pending breakpoints previously created.
|
||
|
|
</p>
|
||
|
|
</dd>
|
||
|
|
<dt><code>show breakpoint pending</code></dt>
|
||
|
|
<dd><p>Show the current behavior setting for creating pending breakpoints.
|
||
|
|
</p></dd>
|
||
|
|
</dl>
|
||
|
|
|
||
|
|
<p>The settings above only affect the <code>break</code> command and its
|
||
|
|
variants. Once breakpoint is set, it will be automatically updated
|
||
|
|
as shared libraries are loaded and unloaded.
|
||
|
|
</p>
|
||
|
|
<a name="index-automatic-hardware-breakpoints"></a>
|
||
|
|
<p>For some targets, <small>GDB</small> can automatically decide if hardware or
|
||
|
|
software breakpoints should be used, depending on whether the
|
||
|
|
breakpoint address is read-only or read-write. This applies to
|
||
|
|
breakpoints set with the <code>break</code> command as well as to internal
|
||
|
|
breakpoints set by commands like <code>next</code> and <code>finish</code>. For
|
||
|
|
breakpoints set with <code>hbreak</code>, <small>GDB</small> will always use hardware
|
||
|
|
breakpoints.
|
||
|
|
</p>
|
||
|
|
<p>You can control this automatic behaviour with the following commands:
|
||
|
|
</p>
|
||
|
|
<a name="index-set-breakpoint-auto_002dhw"></a>
|
||
|
|
<a name="index-show-breakpoint-auto_002dhw"></a>
|
||
|
|
<dl compact="compact">
|
||
|
|
<dt><code>set breakpoint auto-hw on</code></dt>
|
||
|
|
<dd><p>This is the default behavior. When <small>GDB</small> sets a breakpoint, it
|
||
|
|
will try to use the target memory map to decide if software or hardware
|
||
|
|
breakpoint must be used.
|
||
|
|
</p>
|
||
|
|
</dd>
|
||
|
|
<dt><code>set breakpoint auto-hw off</code></dt>
|
||
|
|
<dd><p>This indicates <small>GDB</small> should not automatically select breakpoint
|
||
|
|
type. If the target provides a memory map, <small>GDB</small> will warn when
|
||
|
|
trying to set software breakpoint at a read-only address.
|
||
|
|
</p></dd>
|
||
|
|
</dl>
|
||
|
|
|
||
|
|
<p><small>GDB</small> normally implements breakpoints by replacing the program code
|
||
|
|
at the breakpoint address with a special instruction, which, when
|
||
|
|
executed, given control to the debugger. By default, the program
|
||
|
|
code is so modified only when the program is resumed. As soon as
|
||
|
|
the program stops, <small>GDB</small> restores the original instructions. This
|
||
|
|
behaviour guards against leaving breakpoints inserted in the
|
||
|
|
target should gdb abrubptly disconnect. However, with slow remote
|
||
|
|
targets, inserting and removing breakpoint can reduce the performance.
|
||
|
|
This behavior can be controlled with the following commands::
|
||
|
|
</p>
|
||
|
|
<a name="index-set-breakpoint-always_002dinserted"></a>
|
||
|
|
<a name="index-show-breakpoint-always_002dinserted"></a>
|
||
|
|
<dl compact="compact">
|
||
|
|
<dt><code>set breakpoint always-inserted off</code></dt>
|
||
|
|
<dd><p>All breakpoints, including newly added by the user, are inserted in
|
||
|
|
the target only when the target is resumed. All breakpoints are
|
||
|
|
removed from the target when it stops. This is the default mode.
|
||
|
|
</p>
|
||
|
|
</dd>
|
||
|
|
<dt><code>set breakpoint always-inserted on</code></dt>
|
||
|
|
<dd><p>Causes all breakpoints to be inserted in the target at all times. If
|
||
|
|
the user adds a new breakpoint, or changes an existing breakpoint, the
|
||
|
|
breakpoints in the target are updated immediately. A breakpoint is
|
||
|
|
removed from the target only when breakpoint itself is deleted.
|
||
|
|
</p></dd>
|
||
|
|
</dl>
|
||
|
|
|
||
|
|
<p><small>GDB</small> handles conditional breakpoints by evaluating these conditions
|
||
|
|
when a breakpoint breaks. If the condition is true, then the process being
|
||
|
|
debugged stops, otherwise the process is resumed.
|
||
|
|
</p>
|
||
|
|
<p>If the target supports evaluating conditions on its end, <small>GDB</small> may
|
||
|
|
download the breakpoint, together with its conditions, to it.
|
||
|
|
</p>
|
||
|
|
<p>This feature can be controlled via the following commands:
|
||
|
|
</p>
|
||
|
|
<a name="index-set-breakpoint-condition_002devaluation"></a>
|
||
|
|
<a name="index-show-breakpoint-condition_002devaluation"></a>
|
||
|
|
<dl compact="compact">
|
||
|
|
<dt><code>set breakpoint condition-evaluation host</code></dt>
|
||
|
|
<dd><p>This option commands <small>GDB</small> to evaluate the breakpoint
|
||
|
|
conditions on the host’s side. Unconditional breakpoints are sent to
|
||
|
|
the target which in turn receives the triggers and reports them back to GDB
|
||
|
|
for condition evaluation. This is the standard evaluation mode.
|
||
|
|
</p>
|
||
|
|
</dd>
|
||
|
|
<dt><code>set breakpoint condition-evaluation target</code></dt>
|
||
|
|
<dd><p>This option commands <small>GDB</small> to download breakpoint conditions
|
||
|
|
to the target at the moment of their insertion. The target
|
||
|
|
is responsible for evaluating the conditional expression and reporting
|
||
|
|
breakpoint stop events back to <small>GDB</small> whenever the condition
|
||
|
|
is true. Due to limitations of target-side evaluation, some conditions
|
||
|
|
cannot be evaluated there, e.g., conditions that depend on local data
|
||
|
|
that is only known to the host. Examples include
|
||
|
|
conditional expressions involving convenience variables, complex types
|
||
|
|
that cannot be handled by the agent expression parser and expressions
|
||
|
|
that are too long to be sent over to the target, specially when the
|
||
|
|
target is a remote system. In these cases, the conditions will be
|
||
|
|
evaluated by <small>GDB</small>.
|
||
|
|
</p>
|
||
|
|
</dd>
|
||
|
|
<dt><code>set breakpoint condition-evaluation auto</code></dt>
|
||
|
|
<dd><p>This is the default mode. If the target supports evaluating breakpoint
|
||
|
|
conditions on its end, <small>GDB</small> will download breakpoint conditions to
|
||
|
|
the target (limitations mentioned previously apply). If the target does
|
||
|
|
not support breakpoint condition evaluation, then <small>GDB</small> will fallback
|
||
|
|
to evaluating all these conditions on the host’s side.
|
||
|
|
</p></dd>
|
||
|
|
</dl>
|
||
|
|
|
||
|
|
|
||
|
|
<a name="index-negative-breakpoint-numbers"></a>
|
||
|
|
<a name="index-internal-GDB-breakpoints"></a>
|
||
|
|
<p><small>GDB</small> itself sometimes sets breakpoints in your program for
|
||
|
|
special purposes, such as proper handling of <code>longjmp</code> (in C
|
||
|
|
programs). These internal breakpoints are assigned negative numbers,
|
||
|
|
starting with <code>-1</code>; ‘<samp>info breakpoints</samp>’ does not display them.
|
||
|
|
You can see these breakpoints with the <small>GDB</small> maintenance command
|
||
|
|
‘<samp>maint info breakpoints</samp>’ (see <a href="Maintenance-Commands.html#maint-info-breakpoints">maint info breakpoints</a>).
|
||
|
|
</p>
|
||
|
|
|
||
|
|
<hr>
|
||
|
|
<div class="header">
|
||
|
|
<p>
|
||
|
|
Next: <a href="Set-Watchpoints.html#Set-Watchpoints" accesskey="n" rel="next">Set Watchpoints</a>, Up: <a href="Breakpoints.html#Breakpoints" accesskey="u" rel="up">Breakpoints</a> [<a href="index.html#SEC_Contents" title="Table of contents" rel="contents">Contents</a>][<a href="Concept-Index.html#Concept-Index" title="Index" rel="index">Index</a>]</p>
|
||
|
|
</div>
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
</body>
|
||
|
|
</html>
|