This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: Docs and NEWS for breakpoint changes
On Friday 28 September 2007 00:49:07 Eli Zaretskii wrote:
> > From: Vladimir Prus <vladimir@codesourcery.com>
> > Date: Thu, 27 Sep 2007 22:27:34 +0400
> > Cc: gdb-patches@sources.redhat.com
> >
> > > > +pending breakpoint that never had its address known,
> > >
> > > I think this is better:
> > >
> > > For a pending address whose address is not yet known,
> > ^^^^^^^
> >
> > Did you mean "breakpoint" instead of first "address"?
>
> Yes, sorry.
>
> > > Example, please. A picture is worth a thousand words.
> >
> > I've added one. Is example with a line as long as 75 characters OK?
>
> @smallexample can handle this (which is why we use it instead of
> @example).
>
> > Thanks for review. I attach the revised version.
>
> It's fine, except for a few small gotchas:
>
> > +It is possible that a breakpoints correspond to several locations
> ^^^^^^^^^^^^^^^^^^^^^^^^
> "a breakpoint corresponds".
>
> > +For a C@t{++} constructor, the gcc compiler generates several
> ^^^
> You forgot to replace with @value{NGCC}.
>
> > +by one row for each breakpoint location. The header row
> ^^
> Still only one space.
>
> > +any shared library is loaded or unloaded. Typically, you would
> ^^
> And here.
Thanks. I've checked in the attached.
- Volodya
Index: ChangeLog
===================================================================
RCS file: /cvs/src/src/gdb/ChangeLog,v
retrieving revision 1.8721
diff -u -p -r1.8721 ChangeLog
--- ChangeLog 27 Sep 2007 18:48:32 -0000 1.8721
+++ ChangeLog 28 Sep 2007 06:21:01 -0000
@@ -1,3 +1,8 @@
+2007-09-28 Vladimir Prus <vladimir@codesourcery.com>
+
+ * NEW: Mention pending breakpoint changes and
+ support for breakpoints at multiple locations.
+
2007-09-27 Daniel Jacobowitz <dan@codesourcery.com>
* arm-linux-tdep.c (arm_linux_software_single_step): New.
Index: NEWS
===================================================================
RCS file: /cvs/src/src/gdb/NEWS,v
retrieving revision 1.239
diff -u -p -r1.239 NEWS
--- NEWS 17 Sep 2007 19:30:05 -0000 1.239
+++ NEWS 28 Sep 2007 06:21:03 -0000
@@ -3,6 +3,13 @@
*** Changes since GDB 6.7
+* Pending breakpoints no longer change their number when their address
+ is resolved.
+
+* GDB now supports breakpoints with multiple locations,
+ including breakpoints on C++ constructors, inside C++ templates,
+ and in inlined functions.
+
*** Changes in GDB 6.6
* Resolved 101 resource leaks, null pointer dereferences, etc. in gdb,
Index: doc/ChangeLog
===================================================================
RCS file: /cvs/src/src/gdb/doc/ChangeLog,v
retrieving revision 1.700
diff -u -p -r1.700 ChangeLog
--- doc/ChangeLog 16 Sep 2007 14:59:30 -0000 1.700
+++ doc/ChangeLog 28 Sep 2007 06:21:05 -0000
@@ -1,3 +1,9 @@
+2007-09-28 Vladimir Prus <vladimir@codesourcery.com>
+
+ * gdb.texinfo (Setting Breakpoints): Revise
+ documentation for pending breakpoints. Document
+ breakpoints with multiple locations.
+
2007-09-19 Vladimir Prus <vladimir@codesourcery.com>
* gdb.texinfo (Miscellaneous gdb/mi Commands):
Index: doc/gdb.texinfo
===================================================================
RCS file: /cvs/src/src/gdb/doc/gdb.texinfo,v
retrieving revision 1.432
diff -u -p -r1.432 gdb.texinfo
--- doc/gdb.texinfo 16 Sep 2007 14:59:30 -0000 1.432
+++ doc/gdb.texinfo 28 Sep 2007 06:21:14 -0000
@@ -2991,11 +2991,17 @@ Breakpoint, watchpoint, or catchpoint.
Whether the breakpoint is marked to be disabled or deleted when hit.
@item Enabled or Disabled
Enabled breakpoints are marked with @samp{y}. @samp{n} marks breakpoints
-that are not enabled.
+that are not enabled. An optional @samp{(p)} suffix marks pending
+breakpoints --- breakpoints for which address is either not yet
+resolved, pending load of a shared library, or for which address was
+in a shared library that was since unloaded. Such breakpoint won't
+fire until a shared library that has the symbol or line referred by
+breakpoint is loaded. See below for details.
@item Address
-Where the breakpoint is in your program, as a memory address. If the
-breakpoint is pending (see below for details) on a future load of a shared library, the address
-will be listed as @samp{<PENDING>}.
+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>}. A breakpoint with several locations will
+have @samp{<MULTIPLE>} in this field --- see below for details.
@item What
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
@@ -3032,23 +3038,83 @@ your program. There is nothing silly or
the breakpoints are conditional, this is even useful
(@pxref{Conditions, ,Break Conditions}).
-@cindex pending breakpoints
-If a specified breakpoint location cannot be found, it may be due to the fact
-that the location is in a shared library that is yet to be loaded. In such
-a case, you may want @value{GDBN} to create a special breakpoint (known as
-a @dfn{pending breakpoint}) that
-attempts to resolve itself in the future when an appropriate shared library
-gets loaded.
-
-Pending breakpoints are useful to set at the start of your
-@value{GDBN} session for locations that you know will be dynamically loaded
-later by the program being debugged. When shared libraries are loaded,
-a check is made to see if the load resolves any pending breakpoint locations.
-If a pending breakpoint location gets resolved,
-a regular breakpoint is created and the original pending breakpoint is removed.
+It is possible that a breakpoint correspond to several locations
+in your program. Examples of this situation are:
+
+@itemize @bullet
+
+@item
+For a C@t{++} constructor, the @value{NGCC} compiler generates several
+instances of the function body, used in different cases.
-@value{GDBN} provides some additional commands for controlling pending
-breakpoint support:
+@item
+For a C@t{++} template function, a given line in the function can
+correspond to any number of instantiations.
+
+@item
+For an inlined function, a given source line can correspond to
+several places where that function is inlined.
+
+@end itemize
+
+In all those cases, @value{GDBN} will insert a breakpoint at all
+the relevant locations.
+
+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>} in the address column. The rows for
+individual locations contain the actual addresses for locations,
+and say what functions those locations are in. The number
+column for a location has number in the format
+@var{breakpoint-number}.@var{location-number}.
+
+For example:
+@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
+@end smallexample
+
+Each location can be individually enabled or disabled by passing
+@var{breakpoint-number}.@var{location-number} as argument to the
+@code{enable} and @code{disable} commands.
+
+@cindex pending breakpoints
+It's quite common to have a breakpoint inside a shared library.
+The shared library may be loaded and unloaded explicitly,
+and possibly repeatedly, as the program is executed. To support
+this use case, @value{GDBN} 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, @value{GDBN} will ask you if you want to set
+a so called @dfn{pending breakpoint} --- breakpoint whose address
+is not yet resolved.
+
+After the program is run, whenever a new shared library is loaded,
+@value{GDBN} 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.
+
+This logic works for breakpoints with multiple locations, too. For
+example, if you have a breakpoint in a C@t{++} 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.
+
+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.
+
+@value{GDBN} provides some additional commands for controlling what
+happens when the @samp{break} command cannot resolve breakpoint
+address specification to an address:
@kindex set breakpoint pending
@kindex show breakpoint pending
@@ -3070,19 +3136,9 @@ not affect any pending breakpoints previ
Show the current behavior setting for creating pending breakpoints.
@end table
-@cindex operations allowed on pending breakpoints
-Normal breakpoint operations apply to pending breakpoints as well. You may
-specify a condition for a pending breakpoint and/or commands to run when the
-breakpoint is reached. You can also enable or disable
-the pending breakpoint. When you specify a condition for a pending breakpoint,
-the parsing of the condition will be deferred until the point where the
-pending breakpoint location is resolved. Disabling a pending breakpoint
-tells @value{GDBN} to not attempt to resolve the breakpoint on any subsequent
-shared library load. When a pending breakpoint is re-enabled,
-@value{GDBN} checks to see if the location is already resolved.
-This is done because any number of shared library loads could have
-occurred since the time the breakpoint was disabled and one or more
-of these loads could resolve the location.
+The settings above only affect the @code{break} command and its
+variants. Once breakpoint is set, it will be automatically updated
+as shared libraries are loaded and unloaded.
@cindex automatic hardware breakpoints
For some targets, @value{GDBN} can automatically decide if hardware or