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.