Index: mi/ChangeLog 2003-10-24 Andrew Cagney * tui-out.c: Fix "fortunatly"[sic]. Index: doc/ChangeLog 2003-10-24 Andrew Cagney * annotate.texinfo: Fix "fortunatly"[sic]. 2003-10-24 Andrew Cagney * 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); }