OSDN Git Service

Index: mi/ChangeLog
authorAndrew Cagney <cagney@redhat.com>
Fri, 24 Oct 2003 17:37:04 +0000 (17:37 +0000)
committerAndrew Cagney <cagney@redhat.com>
Fri, 24 Oct 2003 17:37:04 +0000 (17:37 +0000)
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.

24 files changed:
gdb/ChangeLog
gdb/PROBLEMS
gdb/arch-utils.c
gdb/cli-out.c
gdb/command.h
gdb/complaints.c
gdb/cris-tdep.c
gdb/disasm.c
gdb/doc/ChangeLog
gdb/doc/annotate.texinfo
gdb/dwarf2-frame.c
gdb/frame.c
gdb/frame.h
gdb/infcall.c
gdb/infcmd.c
gdb/infrun.c
gdb/kod.c
gdb/mi/ChangeLog
gdb/mips-tdep.c
gdb/osabi.c
gdb/regcache.c
gdb/regcache.h
gdb/remote.c
gdb/tui/tui-out.c

index 176863b..2d00a07 100644 (file)
@@ -1,5 +1,11 @@
 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.
+
        * osabi.c (gdbarch_init_osabi): Add comment on 32-bit vs 64-bit.
        (can_run_code_for): Use the OO term "singleton".
 
index daecf32..cf60d53 100644 (file)
@@ -19,7 +19,7 @@ arm-*-*
 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 5b7a71f..ca0f514 100644 (file)
@@ -626,7 +626,7 @@ initialize_current_architecture (void)
 
 /* 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 2e5a3c1..9f48a0a 100644 (file)
@@ -118,7 +118,7 @@ cli_table_begin (struct ui_out *uiout, int nbrofcols,
   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 9cadd63..c4a5f20 100644 (file)
@@ -157,7 +157,7 @@ extern void execute_cmd_post_hook (struct cmd_list_element *cmd);
    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 252e654..ed24f43 100644 (file)
@@ -210,7 +210,7 @@ vcomplaint (struct complaints **c, const char *file, int line, const char *fmt,
              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 @@ clear_complaints (struct complaints **c, int less_verbose, int noisy)
       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 adb2e74..6c5483b 100644 (file)
@@ -3916,7 +3916,7 @@ cris_version_update (char *ignore_args, int from_tty,
      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 @@ cris_mode_update (char *ignore_args, int from_tty,
      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 @@ cris_abi_update (char *ignore_args, int from_tty,
      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 5f4d07a..20d0ab3 100644 (file)
@@ -337,7 +337,7 @@ gdb_disassemble_info (struct gdbarch *gdbarch, struct ui_file *file)
   /* 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 7e24d82..2e72df7 100644 (file)
@@ -1,3 +1,7 @@
+2003-10-24  Andrew Cagney  <cagney@redhat.com>
+
+       * annotate.texinfo: Fix "fortunatly"[sic].
+
 2003-10-23  Kei Sakamoto  <sakamoto.kei@renesas.com>
 
        * gdb.texinfo (Contributors to GDB): Replace "Renesas"
index 401657d..831d3ca 100644 (file)
@@ -146,7 +146,7 @@ This chapter discusses the known problems.
 @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 b46a382..f97a590 100644 (file)
@@ -770,7 +770,7 @@ dwarf2_frame_prev_register (struct frame_info *next_frame, void **this_cache,
              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 3a4b709..a405a6b 100644 (file)
@@ -65,7 +65,7 @@ struct frame_info
 
   /* 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 @@ get_frame_id (struct frame_info *fi)
          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 @@ frame_pop (struct frame_info *this_frame)
          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_register_unwind (struct frame_info *frame, int regnum,
       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 @@ legacy_saved_regs_prev_register (struct frame_info *next_frame,
                                 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 @@ legacy_get_prev_frame (struct frame_info *this_frame)
      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 @@ legacy_get_prev_frame (struct frame_info *this_frame)
       /* 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 @@ legacy_get_prev_frame (struct frame_info *this_frame)
          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 @@ get_frame_type (struct frame_info *frame)
       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 81f07eb..30d6969 100644 (file)
@@ -629,7 +629,7 @@ extern void return_command (char *, int);
    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 75c7f4e..7695c6a 100644 (file)
@@ -909,7 +909,7 @@ You must use a pointer to function type variable. Command ignored.", arg_name);
     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 9287f03..a7e0e15 100644 (file)
@@ -1127,7 +1127,7 @@ print_return_value (int structure_return, struct type *value_type)
        {
          /* 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 7412080..3a8e121 100644 (file)
@@ -519,7 +519,7 @@ set_schedlock_func (char *args, int from_tty, struct cmd_list_element *c)
      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 @@ process_event_stop_test:
        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 @@ step_over_function (struct execution_control_state *ecs)
      - 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 e2bae91..6cb3622 100644 (file)
--- a/gdb/kod.c
+++ b/gdb/kod.c
@@ -138,7 +138,7 @@ kod_set_os (char *arg, int from_tty, struct cmd_list_element *command)
      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 9a88e2f..cb1ca52 100644 (file)
@@ -1,3 +1,7 @@
+2003-10-24  Andrew Cagney  <cagney@redhat.com>
+
+       * tui-out.c: Fix "fortunatly"[sic].
+
 2003-10-02  Andrew Cagney  <cagney@redhat.com>
 
        * mi-main.c: Rename REGISTER_RAW_SIZE to
index 4440e11..40d8cb4 100644 (file)
@@ -679,7 +679,7 @@ mips_register_raw_size (int regnum)
 /* 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 @@ mips_find_saved_regs (struct frame_info *fci)
                 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 fc712a6..4ebed25 100644 (file)
@@ -337,10 +337,10 @@ gdbarch_init_osabi (struct gdbarch_info info, struct gdbarch *gdbarch)
          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 ccb4e80..62c0de5 100644 (file)
@@ -107,7 +107,7 @@ init_legacy_regcache_descr (struct gdbarch *gdbarch,
   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 @@ init_legacy_regcache_descr (struct gdbarch *gdbarch,
        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 @@ init_regcache_descr (struct gdbarch *gdbarch)
   }
 
   /* 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 9a341c3..26a1b8a 100644 (file)
@@ -140,7 +140,7 @@ extern struct type *register_type (struct gdbarch *gdbarch, int regnum);
 
    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 fc25c61..4b0ff1b 100644 (file)
@@ -204,7 +204,7 @@ void _initialize_remote (void);
 /* 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 @@ remote_open_1 (char *name, int from_tty, struct target_ops *target,
 
      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 e1be56a..1c2af68 100644 (file)
@@ -119,7 +119,7 @@ tui_table_begin (struct ui_out *uiout, int nbrofcols,
   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);
 }