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

This commit is contained in:
Theodore A. Roth
2003-05-14 20:29:15 +00:00
parent de18ac1fab
commit 50e3ee830c
2 changed files with 5 additions and 1 deletions

View File

@ -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> 2003-05-10 H.J. Lu <hongjiu.lu@intel.com>
* Makefile.in (gdb-cfg.texi): Replace $$LN_S with $(LN_S). * Makefile.in (gdb-cfg.texi): Replace $$LN_S with $(LN_S).

View File

@ -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 breakpoints somehow; for instance, a ROM monitor may do its own
software breakpoints. So although these are not literally ``hardware software breakpoints. So although these are not literally ``hardware
breakpoints'', from @value{GDBN}'s point of view they work the same; 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. for something to happen.
Since they depend on hardware resources, hardware breakpoints may be Since they depend on hardware resources, hardware breakpoints may be