Re: [RFC]: pending break support

["J. Johnston" <jjohnstn@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 2091 bytes --]

Eli Zaretskii wrote:
>>Date: Tue, 02 Dec 2003 20:35:01 -0500
>>From: "J. Johnston" <jjohnstn@redhat.com>
>>
>>I have added documentation on the pending breakpoint per Eli's request.
> 
> 
> Thanks.  The documentation patch is approved, but please take care of
> these minor problems:
> 
> 
>>+Where the breakpoint is in your program, as a memory address.  If the
>>+breakpoint is pending on a future load of a shared library, the address
>>+will be listed as <PENDING>.
> 
> 
> First, please add something like "(see below)" after "If the
> breakpoint is pending", since this is the first time the reader meets
> this term.  Second, please say @samp{<PENDING>} to make this stand out.
> 
> 
>>+@cindex pending breakpoints
>>+If a specified breakpoint location cannot be found, you will be prompted
>>+as to whether you want to make the breakpoint pending on a future shared
>>+library load.  This is useful for setting breakpoints at the start of your
>>+@value{GDBN} session for locations that you know will be dynamically loaded
>>+later by the program being debugged.
>>+You may specify
>>+a condition for a pending breakpoint, however, the
>>+condition will only be parsed for correctness after the breakpoint location
>>+is resolved by a future shared library load.  A pending breakpoint can be
>>+enabled or disabled.  A disabled pending breakpoint will not be resolved
>>+on subsequent shared library loads.  Enabling a disabled pending breakpoint
>>+will cause @value{GDBN} to attempt to resolve the breakpoint in the event
>>+that the required shared library has already been loaded.
>>+Once a shared library load resolves a pending breakpoint location, the
>>+pending breakpoint is removed and a real breakpoint is created.
> 
> 
> I think this text should be divided into several paragraphs, as it
> describes several not-so-related aspects of a pending breakpoint.
> 
> TIA
> 

How about the following updated patch?  I tied together why I was talking about 
the various operations on pending breakpoints which makes the grouping of the 
information make more sense.

-- Jeff J.

[-- Attachment #2: penddoc.patch2 --]
[-- Type: text/plain, Size: 3236 bytes --]

Index: gdb.texinfo
===================================================================
RCS file: /cvs/src/src/gdb/doc/gdb.texinfo,v
retrieving revision 1.185
diff -u -r1.185 gdb.texinfo
--- gdb.texinfo	28 Oct 2003 22:04:47 -0000	1.185
+++ gdb.texinfo	3 Dec 2003 19:44:55 -0000
@@ -2600,16 +2600,23 @@
 Enabled breakpoints are marked with @samp{y}.  @samp{n} marks breakpoints
 that are not enabled.
 @item Address
-Where the breakpoint is in your program, as a memory 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>}.
 @item What
 Where the breakpoint is in the source for your program, as a file and
-line number.
+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.
 @end table
 
 @noindent
 If a breakpoint is conditional, @code{info break} shows the condition on
 the line following the affected breakpoint; breakpoint commands, if any,
-are listed after that.
+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.
 
 @noindent
 @code{info break} with a breakpoint
@@ -2631,6 +2638,30 @@
 your program.  There is nothing silly or meaningless about this.  When
 the breakpoints are conditional, this is even useful
 (@pxref{Conditions, ,Break conditions}).
+
+@cindex pending breakpoints
+If a specified breakpoint location cannot be found, you will be prompted
+as to whether you want to make the breakpoint pending on a future shared
+library load.  This is useful for setting breakpoints 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 resoloves any pending breakpoint locations.
+If a pending breakpoint location has been resolved,
+a real breakpoint is created and the original pending breakpoint is removed.
+
+@cindex operations allowed on pending breakpoints 
+Normal breakpoint operations apply to pending breakpoints as well.  You may 
+specify, a condition for a pending breakpoint, commands to run when the 
+breakpoint is reached, and 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.
 
 @cindex negative breakpoint numbers
 @cindex internal @value{GDBN} breakpoints