doc/gdb/Set-Breaks.html

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<!-- Copyright (C) 1988-2021 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 5.1, http://www.gnu.org/software/texinfo/ -->
<head>
<title>Debugging with GDB: Set Breaks</title>

<meta name="description" content="Debugging with GDB: Set Breaks">
<meta name="keywords" content="Debugging with GDB: Set Breaks">
<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="previous" title="Breakpoints">
<style type="text/css">
<!--
a.summary-letter {text-decoration: none}
blockquote.smallquotation {font-size: smaller}
div.display {margin-left: 3.2em}
div.example {margin-left: 3.2em}
div.indentedblock {margin-left: 3.2em}
div.lisp {margin-left: 3.2em}
div.smalldisplay {margin-left: 3.2em}
div.smallexample {margin-left: 3.2em}
div.smallindentedblock {margin-left: 3.2em; font-size: smaller}
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.nocodebreak {white-space:nowrap}
span.nolinebreak {white-space:nowrap}
span.roman {font-family:serif; font-weight:normal}
span.sansserif {font-family:sans-serif; font-weight:normal}
ul.no-bullet {list-style: none}
-->
</style>


</head>

<body lang="en" bgcolor="#FFFFFF" text="#000000" link="#0000FF" vlink="#800080" alink="#FF0000">
<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> &nbsp; [<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 &lsquo;<samp>$bpnum</samp>&rsquo; records the
number of the breakpoint you&rsquo;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&mdash;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 &hellip; 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&mdash;that is, if <var>cond</var> evaluates as true.
&lsquo;<samp>&hellip;</samp>&rsquo; 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
&lsquo;<samp>set language</samp>&rsquo; value: using &lsquo;<samp>set language auto</samp>&rsquo;
(see <a href="Automatically.html#Automatically">Set Language Automatically</a>) means to use the
language of the breakpoint&rsquo;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>&hellip;<span class="roman">]</span></code></dt>
<dt><code>info break <span class="roman">[</span><var>list</var>&hellip;<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 &lsquo;<samp>y</samp>&rsquo;.  &lsquo;<samp>n</samp>&rsquo; 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 &lsquo;<samp>&lt;PENDING&gt;</samp>&rsquo;.  Such breakpoint won&rsquo;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 &lsquo;<samp>&lt;MULTIPLE&gt;</samp>&rsquo; in this field&mdash;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: &ldquo;host&rdquo; and
&ldquo;target&rdquo;.  If mode is &ldquo;host&rdquo;, breakpoint condition evaluation is done by
<small>GDB</small> on the host&rsquo;s side.  If it is &ldquo;target&rdquo;, 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&mdash;one header row, followed by one row for
each breakpoint location.  The header row has &lsquo;<samp>&lt;MULTIPLE&gt;</samp>&rsquo; 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    &lt;MULTIPLE&gt;
        stop only if i==1
        breakpoint already hit 1 time
1.1                         y    0x080486a2 in void foo&lt;int&gt;() at t.cc:8
1.2                         y    0x080486ca in void foo&lt;double&gt;() 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&rsquo;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&rsquo;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>&mdash;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 &lsquo;<samp>break</samp>&rsquo; 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&rsquo;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&rsquo;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>; &lsquo;<samp>info breakpoints</samp>&rsquo; does not display them.
You can see these breakpoints with the <small>GDB</small> maintenance command
&lsquo;<samp>maint info breakpoints</samp>&rsquo; (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> &nbsp; [<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>