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.
This commit is contained in:
Andrew Cagney 2003-10-24 17:37:04 +00:00
parent ea8f8eab20
commit ce2826aa7a
24 changed files with 54 additions and 40 deletions

View 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".

View 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).

View 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. */

View 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);
}

View 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?). */

View 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;

View 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?). */

View 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

View 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"

View 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.

View 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

View 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);

View 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

View 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

View 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);

View 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.

View File

@ -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?). */

View 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

View 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

View 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);

View 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! */

View 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.

View 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

View 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);
}