* gdbint.texinfo (Breakpoint Handling): Correct a double negative.

diff --git a/gdb/doc/ChangeLog b/gdb/doc/ChangeLog
index f8e992db1bc8df36920ad6505e9314586f786559..ba39d428822ee0aa1c7f668669b5ba1025cf7623 100644 (file)
--- a/gdb/doc/ChangeLog
+++ b/gdb/doc/ChangeLog
@@ -1,3 +1,7 @@
+2003-05-14  Theodore A. Roth  <troth@openavr.org>
+
+       * gdbint.texinfo (Breakpoint Handling): Correct a double negative.
+
 2003-05-10  H.J. Lu <hongjiu.lu@intel.com>
 
        * Makefile.in (gdb-cfg.texi): Replace $$LN_S with $(LN_S).

diff --git a/gdb/doc/gdbint.texinfo b/gdb/doc/gdbint.texinfo
index 28cdc82242aa38312416341f6a158d681a51da57..12bd4040c41c51488ffe3600961e260637af6993 100644 (file)
--- a/gdb/doc/gdbint.texinfo
+++ b/gdb/doc/gdbint.texinfo
@@ -288,7 +288,7 @@ A third possibility is that the target already has the ability to do
 breakpoints somehow; for instance, a ROM monitor may do its own
 software breakpoints.  So although these are not literally ``hardware
 breakpoints'', from @value{GDBN}'s point of view they work the same;
-@value{GDBN} need not do nothing more than set the breakpoint and wait
+@value{GDBN} need not do anything more than set the breakpoint and wait
 for something to happen.
 
 Since they depend on hardware resources, hardware breakpoints may be