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".
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).
/* 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. */
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);
}
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?). */
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);
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;
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?). */
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?). */
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?). */
/* 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"
@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.
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
/* 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;
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);
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.
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);
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.
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;
/* 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
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;
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);
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
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
{
/* 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);
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?). */
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 ());
- 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.
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
/* 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. */
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
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);
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. */
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;
}
}
/* 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! */
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.
/* 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.. */
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
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);
}
projects / binutils-gdb.git / commitdiff