Commit ce2826aa authored by Andrew Cagney's avatar Andrew Cagney
Browse files

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.
parent ea8f8eab
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".
 
......
......@@ -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).
......
......@@ -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. */
......
......@@ -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);
}
......
......@@ -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?). */
......
......@@ -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;
......
......@@ -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?). */
......
......@@ -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
......
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"
......
......@@ -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.
......
......@@ -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
......
......@@ -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);
......
......@@ -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
......
......@@ -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
......
......@@ -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);
......
......@@ -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.
......
......@@ -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?). */
......
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
......
......@@ -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
......
......@@ -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);
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment