* 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