From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32571 invoked by alias); 3 Dec 2003 19:46:51 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 32563 invoked from network); 3 Dec 2003 19:46:50 -0000 Received: from unknown (HELO touchme.toronto.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 3 Dec 2003 19:46:50 -0000 Received: from redhat.com (toocool.toronto.redhat.com [172.16.14.72]) by touchme.toronto.redhat.com (Postfix) with ESMTP id 83D6980018E; Wed, 3 Dec 2003 14:46:49 -0500 (EST) Message-ID: <3FCE3DA9.2000603@redhat.com> Date: Wed, 03 Dec 2003 19:46:00 -0000 From: "J. Johnston" Organization: Red Hat Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eli Zaretskii Cc: gdb-patches@sources.redhat.com Subject: Re: [RFC]: pending break support References: <3FCD3DC5.8000308@redhat.com> <3405-Wed03Dec2003180427+0200-eliz@elta.co.il> In-Reply-To: <3405-Wed03Dec2003180427+0200-eliz@elta.co.il> Content-Type: multipart/mixed; boundary="------------090302040706090006000403" X-SW-Source: 2003-12/txt/msg00094.txt.bz2 This is a multi-part message in MIME format. --------------090302040706090006000403 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-length: 2091 Eli Zaretskii wrote: >>Date: Tue, 02 Dec 2003 20:35:01 -0500 >>From: "J. Johnston" >> >>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 . > > > 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{} 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. --------------090302040706090006000403 Content-Type: text/plain; name="penddoc.patch2" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="penddoc.patch2" Content-length: 3236 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{}. @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 --------------090302040706090006000403--