* [ob] Fix typos
@ 2003-10-24 17:37 Andrew Cagney
2003-10-24 17:56 ` Andrew Cagney
0 siblings, 1 reply; 2+ messages in thread
From: Andrew Cagney @ 2003-10-24 17:37 UTC (permalink / raw)
To: gdb-patches
[-- Attachment #1: Type: text/plain, Size: 39 bytes --]
Just one or two ...
committed,
Andrew
[-- Attachment #2: diffs --]
[-- Type: text/plain, Size: 1864 bytes --]
2003-10-24 Andrew Cagney <cagney@redhat.com>
* osabi.c (gdbarch_init_osabi): Add comment on 32-bit vs 64-bit.
(can_run_code_for): Use the OO term "singleton".
Index: osabi.c
===================================================================
RCS file: /cvs/src/src/gdb/osabi.c,v
retrieving revision 1.18
diff -u -r1.18 osabi.c
--- osabi.c 23 Oct 2003 21:15:50 -0000 1.18
+++ osabi.c 24 Oct 2003 15:35:26 -0000
@@ -295,9 +295,9 @@
written for B, but B can't run code written for A, then it'll
return A.
- struct bfd_arch_info objects are atoms: that is, there's supposed
- to be exactly one instance for a given machine. So you can tell
- whether two are equivalent by comparing pointers. */
+ struct bfd_arch_info objects are singletons: that is, there's
+ supposed to be exactly one instance for a given machine. So you
+ can tell whether two are equivalent by comparing pointers. */
return (a == b || a->compatible (a, b) == a);
}
@@ -333,6 +333,14 @@
type that is compatible with the desired machine type. Right
now we simply return the first match, which is fine for now.
However, we might want to do something smarter in the future. */
+ /* NOTE: cagney/2003-10-23: The code for "a can_run_code_for b"
+ is implemented using BFD's compatible method (a->compatible
+ (b) == a -- the lowest common denominator between a and b is
+ a). That method's definition of compatible may not be as you
+ expect. For instance, while "amd64 can run code for i386"
+ (or more generally "64-bit ISA can run code for the 32-bit
+ ISA"). Fortunatly, BFD doesn't normally consider 32-bit and
+ 64-bit "compatible" so won't get a match. */
if (can_run_code_for (arch_info, handler->arch_info))
{
(*handler->init_osabi) (info, gdbarch);
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [ob] Fix typos
2003-10-24 17:37 [ob] Fix typos Andrew Cagney
@ 2003-10-24 17:56 ` Andrew Cagney
0 siblings, 0 replies; 2+ messages in thread
From: Andrew Cagney @ 2003-10-24 17:56 UTC (permalink / raw)
To: gdb-patches
[-- Attachment #1: Type: text/plain, Size: 27 bytes --]
Ulgh, wrong patch.
Andrew
[-- Attachment #2: diffs --]
[-- Type: text/plain, Size: 23680 bytes --]
Index: mi/ChangeLog
2003-10-24 Andrew Cagney <cagney@redhat.com>
* tui-out.c: Fix "fortunatly"[sic].
Index: doc/ChangeLog
2003-10-24 Andrew Cagney <cagney@redhat.com>
* annotate.texinfo: Fix "fortunatly"[sic].
2003-10-24 Andrew Cagney <cagney@redhat.com>
* osabi.c (gdbarch_init_osabi): Fix typos, and "fortunatly"[sic].
* PROBLEMS, arch-utils.c, cli-out.c, command.h: Ditto.
* complaints.c, cris-tdep.c, disasm.c, dwarf2-frame.c: Ditto.
* frame.c, frame.h, infcall.c, infcmd.c, infrun.c: Ditto.
* kod.c, mips-tdep.c, regcache.c, regcache.h, remote.c: Ditto.
Index: PROBLEMS
===================================================================
RCS file: /cvs/src/src/gdb/PROBLEMS,v
retrieving revision 1.19
diff -u -r1.19 PROBLEMS
--- PROBLEMS 25 Sep 2003 18:23:56 -0000 1.19
+++ PROBLEMS 24 Oct 2003 17:34:42 -0000
@@ -19,7 +19,7 @@
GDB's ARM target, in 6.0, has not been updated to use the new frame
mechanism.
-Fortunatly the ARM target, in the GDB's mainline sources, has been
+Fortunately the ARM target, in the GDB's mainline sources, has been
updated so people encountering problems should consider downloading a
more current GDB (http://www.gnu.org/software/gdb/current).
Index: arch-utils.c
===================================================================
RCS file: /cvs/src/src/gdb/arch-utils.c,v
retrieving revision 1.98
diff -u -r1.98 arch-utils.c
--- arch-utils.c 22 Oct 2003 23:54:10 -0000 1.98
+++ arch-utils.c 24 Oct 2003 17:34:42 -0000
@@ -626,7 +626,7 @@
/* Initialize a gdbarch info to values that will be automatically
overridden. Note: Originally, this ``struct info'' was initialized
- using memset(0). Unfortunatly, that ran into problems, namely
+ using memset(0). Unfortunately, that ran into problems, namely
BFD_ENDIAN_BIG is zero. An explicit initialization function that
can explicitly set each field to a well defined value is used. */
Index: cli-out.c
===================================================================
RCS file: /cvs/src/src/gdb/cli-out.c,v
retrieving revision 1.17
diff -u -r1.17 cli-out.c
--- cli-out.c 28 Jun 2003 16:19:05 -0000 1.17
+++ cli-out.c 24 Oct 2003 17:34:42 -0000
@@ -118,7 +118,7 @@
if (nr_rows == 0)
data->suppress_output = 1;
else
- /* Only the table suppresses the output and, fortunatly, a table
+ /* Only the table suppresses the output and, fortunately, a table
is not a recursive data structure. */
gdb_assert (data->suppress_output == 0);
}
Index: command.h
===================================================================
RCS file: /cvs/src/src/gdb/command.h,v
retrieving revision 1.36
diff -u -r1.36 command.h
--- command.h 9 Aug 2003 15:10:08 -0000 1.36
+++ command.h 24 Oct 2003 17:34:42 -0000
@@ -157,7 +157,7 @@
the set command passed as a parameter. The clone operation will
include (BUG?) any ``set'' command callback, if present. Commands
like ``info set'' call all the ``show'' command callbacks.
- Unfortunatly, for ``show'' commands cloned from ``set'', this
+ Unfortunately, for ``show'' commands cloned from ``set'', this
includes callbacks belonging to ``set'' commands. Making this
worse, this only occures if add_show_from_set() is called after
add_cmd_sfunc() (BUG?). */
Index: complaints.c
===================================================================
RCS file: /cvs/src/src/gdb/complaints.c,v
retrieving revision 1.11
diff -u -r1.11 complaints.c
--- complaints.c 15 Jul 2003 15:36:13 -0000 1.11
+++ complaints.c 24 Oct 2003 17:34:42 -0000
@@ -210,7 +210,7 @@
trailing newline, the wrap_here() is just a hint. */
if (series == ISOLATED_MESSAGE)
/* It would be really nice to use begin_line() here.
- Unfortunatly that function doesn't track GDB_STDERR and
+ Unfortunately that function doesn't track GDB_STDERR and
consequently will sometimes supress a line when it
shouldn't. */
fputs_filtered ("\n", gdb_stderr);
@@ -292,7 +292,7 @@
break;
case SUBSEQUENT_MESSAGE:
/* It would be really nice to use begin_line() here.
- Unfortunatly that function doesn't track GDB_STDERR and
+ Unfortunately that function doesn't track GDB_STDERR and
consequently will sometimes supress a line when it shouldn't. */
fputs_unfiltered ("\n", gdb_stderr);
break;
Index: cris-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/cris-tdep.c,v
retrieving revision 1.90
diff -u -r1.90 cris-tdep.c
--- cris-tdep.c 2 Oct 2003 20:28:29 -0000 1.90
+++ cris-tdep.c 24 Oct 2003 17:34:42 -0000
@@ -3916,7 +3916,7 @@
the set command passed as a parameter. The clone operation will
include (BUG?) any ``set'' command callback, if present.
Commands like ``info set'' call all the ``show'' command
- callbacks. Unfortunatly, for ``show'' commands cloned from
+ callbacks. Unfortunately, for ``show'' commands cloned from
``set'', this includes callbacks belonging to ``set'' commands.
Making this worse, this only occures if add_show_from_set() is
called after add_cmd_sfunc() (BUG?). */
@@ -3943,7 +3943,7 @@
the set command passed as a parameter. The clone operation will
include (BUG?) any ``set'' command callback, if present.
Commands like ``info set'' call all the ``show'' command
- callbacks. Unfortunatly, for ``show'' commands cloned from
+ callbacks. Unfortunately, for ``show'' commands cloned from
``set'', this includes callbacks belonging to ``set'' commands.
Making this worse, this only occures if add_show_from_set() is
called after add_cmd_sfunc() (BUG?). */
@@ -3970,7 +3970,7 @@
the set command passed as a parameter. The clone operation will
include (BUG?) any ``set'' command callback, if present.
Commands like ``info set'' call all the ``show'' command
- callbacks. Unfortunatly, for ``show'' commands cloned from
+ callbacks. Unfortunately, for ``show'' commands cloned from
``set'', this includes callbacks belonging to ``set'' commands.
Making this worse, this only occures if add_show_from_set() is
called after add_cmd_sfunc() (BUG?). */
Index: disasm.c
===================================================================
RCS file: /cvs/src/src/gdb/disasm.c,v
retrieving revision 1.16
diff -u -r1.16 disasm.c
--- disasm.c 9 Sep 2003 04:41:32 -0000 1.16
+++ disasm.c 24 Oct 2003 17:34:43 -0000
@@ -337,7 +337,7 @@
/* NOTE: cagney/2003-04-28: The original code, from the old Insight
disassembler had a local optomization here. By default it would
access the executable file, instead of the target memory (there
- was a growing list of exceptions though). Unfortunatly, the
+ was a growing list of exceptions though). Unfortunately, the
heuristic was flawed. Commands like "disassemble &variable"
didn't work as they relied on the access going to the target.
Further, it has been supperseeded by trust-read-only-sections
Index: dwarf2-frame.c
===================================================================
RCS file: /cvs/src/src/gdb/dwarf2-frame.c,v
retrieving revision 1.16
diff -u -r1.16 dwarf2-frame.c
--- dwarf2-frame.c 3 Oct 2003 08:08:27 -0000 1.16
+++ dwarf2-frame.c 24 Oct 2003 17:34:43 -0000
@@ -770,7 +770,7 @@
either a register and a signed offset that are added
together or a DWARF expression that is evaluated. */
/* NOTE: cagney/2003-09-05: Should issue a complain.
- Unfortunatly it turns out that DWARF2 CFI has a problem.
+ Unfortunately it turns out that DWARF2 CFI has a problem.
Since CFI specifies the location at which a register was
saved (not its value) it isn't possible to specify
something like "unwound(REG) == REG + constant" using CFI
Index: frame.c
===================================================================
RCS file: /cvs/src/src/gdb/frame.c,v
retrieving revision 1.146
diff -u -r1.146 frame.c
--- frame.c 17 Oct 2003 16:32:17 -0000 1.146
+++ frame.c 24 Oct 2003 17:34:43 -0000
@@ -65,7 +65,7 @@
/* The frame's type. */
/* FIXME: cagney/2003-04-02: Should instead be returning
- ->unwind->type. Unfortunatly, legacy code is still explicitly
+ ->unwind->type. Unfortunately, legacy code is still explicitly
setting the type using the method deprecated_set_frame_type.
Eliminate that method and this field can be eliminated. */
enum frame_type type;
@@ -235,7 +235,7 @@
fi->unwind = frame_unwind_find_by_frame (fi->next);
/* FIXME: cagney/2003-04-02: Rather than storing the frame's
type in the frame, the unwinder's type should be returned
- directly. Unfortunatly, legacy code, called by
+ directly. Unfortunately, legacy code, called by
legacy_get_prev_frame, explicitly set the frames type
using the method deprecated_set_frame_type(). */
gdb_assert (fi->unwind->type != UNKNOWN_FRAME);
@@ -492,7 +492,7 @@
burst register transfer and that the sequence of register
writes should be batched. The pair target_prepare_to_store()
and target_store_registers() kind of suggest this
- functionality. Unfortunatly, they don't implement it. Their
+ functionality. Unfortunately, they don't implement it. Their
lack of a formal definition can lead to targets writing back
bogus values (arguably a bug in the target code mind). */
/* Now copy those saved registers into the current regcache.
@@ -539,7 +539,7 @@
frame->unwind = frame_unwind_find_by_frame (frame->next);
/* FIXME: cagney/2003-04-02: Rather than storing the frame's
type in the frame, the unwinder's type should be returned
- directly. Unfortunatly, legacy code, called by
+ directly. Unfortunately, legacy code, called by
legacy_get_prev_frame, explicitly set the frames type using
the method deprecated_set_frame_type(). */
gdb_assert (frame->unwind->type != UNKNOWN_FRAME);
@@ -953,7 +953,7 @@
int *realnump, void *bufferp)
{
/* HACK: New code is passed the next frame and this cache.
- Unfortunatly, old code expects this frame. Since this is a
+ Unfortunately, old code expects this frame. Since this is a
backward compatibility hack, cheat by walking one level along the
prologue chain to the frame the old code expects.
@@ -1309,7 +1309,7 @@
DEPRECATED_INIT_FRAME_PC_FIRST and
DEPRECATED_FRAME_INIT_SAVED_REGS methods are full of work-arounds
that handle the frame not being correctly set from the start.
- Unfortunatly those same work-arounds rely on the type defaulting
+ Unfortunately those same work-arounds rely on the type defaulting
to NORMAL_FRAME. Ulgh! The new frame code does not have this
problem. */
prev->type = UNKNOWN_FRAME;
@@ -1419,7 +1419,7 @@
/* FIXME: cagney/2002-01-19: This call will go away. Instead of
initializing extra info, all frames will use the frame_cache
(passed to the unwind functions) to store additional frame
- info. Unfortunatly legacy targets can't use
+ info. Unfortunately legacy targets can't use
legacy_get_prev_frame() to unwind the sentinel frame and,
consequently, are forced to take this code path and rely on
the below call to DEPRECATED_INIT_EXTRA_FRAME_INFO to
@@ -1506,7 +1506,7 @@
prev->unwind = frame_unwind_find_by_frame (this_frame->next);
/* FIXME: cagney/2003-04-02: Rather than storing the frame's
type in the frame, the unwinder's type should be returned
- directly. Unfortunatly, legacy code, called by
+ directly. Unfortunately, legacy code, called by
legacy_get_prev_frame, explicitly set the frames type
using the method deprecated_set_frame_type(). */
prev->type = prev->unwind->type;
@@ -2159,7 +2159,7 @@
frame->unwind = frame_unwind_find_by_frame (frame->next);
/* FIXME: cagney/2003-04-02: Rather than storing the frame's
type in the frame, the unwinder's type should be returned
- directly. Unfortunatly, legacy code, called by
+ directly. Unfortunately, legacy code, called by
legacy_get_prev_frame, explicitly set the frames type using
the method deprecated_set_frame_type(). */
gdb_assert (frame->unwind->type != UNKNOWN_FRAME);
Index: frame.h
===================================================================
RCS file: /cvs/src/src/gdb/frame.h,v
retrieving revision 1.111
diff -u -r1.111 frame.h
--- frame.h 17 Oct 2003 16:32:17 -0000 1.111
+++ frame.h 24 Oct 2003 17:34:44 -0000
@@ -629,7 +629,7 @@
You might think that the below global can simply be replaced by a
call to either get_selected_frame() or select_frame().
- Unfortunatly, it isn't that easy.
+ Unfortunately, it isn't that easy.
The relevant code needs to be audited to determine if it is
possible (or pratical) to instead pass the applicable frame in as a
Index: infcall.c
===================================================================
RCS file: /cvs/src/src/gdb/infcall.c,v
retrieving revision 1.34
diff -u -r1.34 infcall.c
--- infcall.c 22 Oct 2003 23:54:11 -0000 1.34
+++ infcall.c 24 Oct 2003 17:34:44 -0000
@@ -909,7 +909,7 @@
else
{
/* The assumption here is that push_dummy_call() returned the
- stack part of the frame ID. Unfortunatly, many older
+ stack part of the frame ID. Unfortunately, many older
architectures were, via a convoluted mess, relying on the
poorly defined and greatly overloaded
DEPRECATED_TARGET_READ_FP or DEPRECATED_FP_REGNUM to supply
Index: infcmd.c
===================================================================
RCS file: /cvs/src/src/gdb/infcmd.c,v
retrieving revision 1.97
diff -u -r1.97 infcmd.c
--- infcmd.c 20 Oct 2003 15:38:02 -0000 1.97
+++ infcmd.c 24 Oct 2003 17:34:44 -0000
@@ -1127,7 +1127,7 @@
{
/* It is "struct return" yet the value is being extracted,
presumably from registers, using EXTRACT_RETURN_VALUE.
- This doesn't make sense. Unfortunatly, the legacy
+ This doesn't make sense. Unfortunately, the legacy
interfaces allowed this behavior. Sigh! */
value = allocate_value (value_type);
CHECK_TYPEDEF (value_type);
Index: infrun.c
===================================================================
RCS file: /cvs/src/src/gdb/infrun.c,v
retrieving revision 1.116
diff -u -r1.116 infrun.c
--- infrun.c 16 Oct 2003 18:24:13 -0000 1.116
+++ infrun.c 24 Oct 2003 17:34:45 -0000
@@ -519,7 +519,7 @@
the set command passed as a parameter. The clone operation will
include (BUG?) any ``set'' command callback, if present.
Commands like ``info set'' call all the ``show'' command
- callbacks. Unfortunatly, for ``show'' commands cloned from
+ callbacks. Unfortunately, for ``show'' commands cloned from
``set'', this includes callbacks belonging to ``set'' commands.
Making this worse, this only occures if add_show_from_set() is
called after add_cmd_sfunc() (BUG?). */
@@ -2650,7 +2650,7 @@
stepped out of a function;
/* Of course this assumes that the frame ID unwind code is robust
and we're willing to introduce frame unwind logic into this
- function. Fortunatly, those days are nearly upon us. */
+ function. Fortunately, those days are nearly upon us. */
#endif
{
struct frame_id current_frame = get_frame_id (get_current_frame ());
@@ -2807,7 +2807,7 @@
- avoid handling the case where the PC hasn't been saved in the
prologue analyzer
- Unfortunatly, not five lines further down, is a call to
+ Unfortunately, not five lines further down, is a call to
get_frame_id() and that is guarenteed to trigger the prologue
analyzer.
Index: kod.c
===================================================================
RCS file: /cvs/src/src/gdb/kod.c,v
retrieving revision 1.9
diff -u -r1.9 kod.c
--- kod.c 17 Oct 2003 18:24:49 -0000 1.9
+++ kod.c 24 Oct 2003 17:34:45 -0000
@@ -138,7 +138,7 @@
the set command passed as a parameter. The clone operation will
include (BUG?) any ``set'' command callback, if present.
Commands like ``info set'' call all the ``show'' command
- callbacks. Unfortunatly, for ``show'' commands cloned from
+ callbacks. Unfortunately, for ``show'' commands cloned from
``set'', this includes callbacks belonging to ``set'' commands.
Making this worse, this only occures if add_show_from_set() is
called after add_cmd_sfunc() (BUG?). */
Index: mips-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/mips-tdep.c,v
retrieving revision 1.240
diff -u -r1.240 mips-tdep.c
--- mips-tdep.c 2 Oct 2003 20:28:29 -0000 1.240
+++ mips-tdep.c 24 Oct 2003 17:34:46 -0000
@@ -679,7 +679,7 @@
/* Register offset in a buffer for each register.
FIXME: cagney/2003-06-15: This is so bogus. Instead REGISTER_TYPE
- should strictly return the layout of the buffer. Unfortunatly
+ should strictly return the layout of the buffer. Unfortunately
remote.c and the MIPS have come to rely on a custom layout that
doesn't 1:1 map onto the register type. */
@@ -1741,7 +1741,7 @@
stored first leading to the memory order $f[N] and
then $f[N+1].
- Unfortunatly, when big-endian the most significant
+ Unfortunately, when big-endian the most significant
part of the double is stored first, and the least
significant is stored second. This leads to the
registers being ordered in memory as firt $f[N+1] and
Index: osabi.c
===================================================================
RCS file: /cvs/src/src/gdb/osabi.c,v
retrieving revision 1.19
diff -u -r1.19 osabi.c
--- osabi.c 24 Oct 2003 15:36:17 -0000 1.19
+++ osabi.c 24 Oct 2003 17:34:46 -0000
@@ -337,10 +337,10 @@
is implemented using BFD's compatible method (a->compatible
(b) == a -- the lowest common denominator between a and b is
a). That method's definition of compatible may not be as you
- expect. For instance, while "amd64 can run code for i386"
+ expect. For instance the test "amd64 can run code for i386"
(or more generally "64-bit ISA can run code for the 32-bit
- ISA"). Fortunatly, BFD doesn't normally consider 32-bit and
- 64-bit "compatible" so won't get a match. */
+ ISA"). BFD doesn't normally consider 32-bit and 64-bit
+ "compatible" so it doesn't succeed. */
if (can_run_code_for (arch_info, handler->arch_info))
{
(*handler->init_osabi) (info, gdbarch);
Index: regcache.c
===================================================================
RCS file: /cvs/src/src/gdb/regcache.c,v
retrieving revision 1.104
diff -u -r1.104 regcache.c
--- regcache.c 2 Oct 2003 20:28:30 -0000 1.104
+++ regcache.c 24 Oct 2003 17:34:47 -0000
@@ -107,7 +107,7 @@
for (i = 0; i < descr->nr_cooked_registers; i++)
{
/* FIXME: cagney/2001-12-04: This code shouldn't need to use
- DEPRECATED_REGISTER_BYTE(). Unfortunatly, legacy code likes
+ DEPRECATED_REGISTER_BYTE(). Unfortunately, legacy code likes
to lay the buffer out so that certain registers just happen
to overlap. Ulgh! New targets use gdbarch's register
read/write and entirely avoid this uglyness. */
@@ -138,7 +138,7 @@
descr->sizeof_cooked_registers = regend;
}
/* FIXME: cagney/2002-05-11: Shouldn't be including pseudo-registers
- in the register cache. Unfortunatly some architectures still
+ in the register cache. Unfortunately some architectures still
rely on this and the pseudo_register_write() method. */
descr->sizeof_raw_registers = descr->sizeof_cooked_registers;
}
@@ -229,7 +229,7 @@
}
/* FIXME: cagney/2002-05-22: Should only need to allocate space for
- the raw registers. Unfortunatly some code still accesses the
+ the raw registers. Unfortunately some code still accesses the
register array directly using the global registers[]. Until that
code has been purged, play safe and over allocating the register
buffer. Ulgh! */
Index: regcache.h
===================================================================
RCS file: /cvs/src/src/gdb/regcache.h,v
retrieving revision 1.39
diff -u -r1.39 regcache.h
--- regcache.h 30 Sep 2003 19:12:19 -0000 1.39
+++ regcache.h 24 Oct 2003 17:34:47 -0000
@@ -140,7 +140,7 @@
FIXME: cagney/2003-02-28:
- Unfortunatly, thanks to some legacy architectures, this doesn't
+ Unfortunately, thanks to some legacy architectures, this doesn't
hold. A register's cooked (nee virtual) and raw size can differ
(see MIPS). Such architectures should be using different register
numbers for the different sized views of identical registers.
Index: remote.c
===================================================================
RCS file: /cvs/src/src/gdb/remote.c,v
retrieving revision 1.119
diff -u -r1.119 remote.c
--- remote.c 17 Oct 2003 18:24:49 -0000 1.119
+++ remote.c 24 Oct 2003 17:34:48 -0000
@@ -204,7 +204,7 @@
/* Description of the remote protocol. Strictly speaking, when the
target is open()ed, remote.c should create a per-target description
of the remote protocol using that target's architecture.
- Unfortunatly, the target stack doesn't include local state. For
+ Unfortunately, the target stack doesn't include local state. For
the moment keep the information in the target's architecture
object. Sigh.. */
@@ -2365,7 +2365,7 @@
FIXME: cagney/2002-05-19: Instead of re-throwing the exception,
this function should return an error indication letting the
- caller restore the previous state. Unfortunatly the command
+ caller restore the previous state. Unfortunately the command
``target remote'' is directly wired to this function making that
impossible. On a positive note, the CLI side of this problem has
been fixed - the function set_cmd_context() makes it possible for
Index: doc/annotate.texinfo
===================================================================
RCS file: /cvs/src/src/gdb/doc/annotate.texinfo,v
retrieving revision 1.1
diff -u -r1.1 annotate.texinfo
--- doc/annotate.texinfo 30 Jul 2003 04:14:38 -0000 1.1
+++ doc/annotate.texinfo 24 Oct 2003 17:34:49 -0000
@@ -146,7 +146,7 @@
@section Dependant on @sc{cli} output
The annotation interface works by interspersing markups with
-@value{GDBN} normal command-line interpreter output. Unfortunatly, this
+@value{GDBN} normal command-line interpreter output. Unfortunately, this
makes the annotation client dependant on not just the annotations, but
also the @sc{cli} output. This is because the client is forced to
assume that specific @value{GDBN} commands provide specific information.
Index: tui/tui-out.c
===================================================================
RCS file: /cvs/src/src/gdb/tui/tui-out.c,v
retrieving revision 1.6
diff -u -r1.6 tui-out.c
--- tui/tui-out.c 28 Jun 2003 16:19:07 -0000 1.6
+++ tui/tui-out.c 24 Oct 2003 17:34:49 -0000
@@ -119,7 +119,7 @@
if (nr_rows == 0)
data->suppress_output = 1;
else
- /* Only the table suppresses the output and, fortunatly, a table
+ /* Only the table suppresses the output and, fortunately, a table
is not a recursive data structure. */
gdb_assert (data->suppress_output == 0);
}
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2003-10-24 17:56 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-10-24 17:37 [ob] Fix typos Andrew Cagney
2003-10-24 17:56 ` Andrew Cagney
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox