Fix typos (#397)

* Fix typos

* Cleanup trailing whitespaces in committed files

* Update include/tdep-ia64/libunwind_i.h

23 files changed, 373 insertions, 373 deletions

diff --git a/NEWS b/NEWS
index ae6cbcfb..adf449ed 100644
--- a/NEWS
+++ b/NEWS
@@ -28,11 +28,11 @@
 
 * News for v1.0:
 
-** Fast unwind (rbp, rsp, rip only) on x86_64 with a fallback to 
+** Fast unwind (rbp, rsp, rip only) on x86_64 with a fallback to
    slow code path (Lassi Tuura)
 ** Improved local and remote unwinding on ARM (Ken Werner)
 ** Testing, stability and many fixes on x86 (Paul Pluzhnikov)
-** FreeBSD port and clean separation of OS specific bits 
+** FreeBSD port and clean separation of OS specific bits
    (Konstantin Belousov)
 ** Thanks for all the bug reports, contributions and testing!
 
@@ -108,7 +108,7 @@
 * News for v0.98:
 
 ** Update libunwind to be compliant with the updated/expanded
-   ia64 unwind specificiation by HJ Lu [1].  This is needed for
+   ia64 unwind specification by HJ Lu [1].  This is needed for
    GCC 3.4 compatibility.
 
    [1] http://www.kernel.org/pub/linux/devel/gcc/unwind/
@@ -116,7 +116,7 @@
 ** Initial support for x86-64 has been added courtesy of Max Asbock.
    Along with this came a bunch of DWARF2 unwinder fixes.
 
-** A new rountine unw_strerror() has been added courtesy of
+** A new routine unw_strerror() has been added courtesy of
    Thomas Hallgren.
 
 ** Including <libunwind.h> now defines 4 macros that can be used
@@ -188,40 +188,40 @@
    at IBM and it is expected that this support will be merged into the
    official tree soon.
 
-
+
 * News for v0.96:
 
 ** _Unwind_*() routines defined by the C++ ABI are now included in
    libunwind.
 
-
+
 * News for v0.95:
 
 ** Bigger, better, faster, or so the theory goes.
 
-
+
 * News for v0.93:
 
 ** More bug-fixes & improved HP-UX support.
 
-
+
 * News for v0.92:
 
 ** Bug-fix release.  IA-64 unwinder can now be built with Intel compiler (ECC).
 
-
+
 * News for v0.91:
 
 ** Lots of documentation updates
 ** Some portability fixes.
 
-
+
 * News for v0.9:
 
 ** The libunwind API is mostly feature-complete at this point (hence the
    version jump from v0.2 to v0.9).
 
-
+
 * News for v0.2:
 
 ** Automated configuration/build with autoconf and automake.
@@ -236,12 +236,12 @@
    e.g., useful for building a debugger that can support multiple targets
    such as x86, ia64, etc.)
 
-
+
 * News for v0.1:
 
 ** Added support for exception handling.
 
-
+
 * News for v0.0:
 
 ** It's a brand new package.
diff --git a/configure.ac b/configure.ac
index 63f1ea74..9a4c887d 100644
--- a/configure.ac
+++ b/configure.ac
@@ -335,7 +335,7 @@ AM_CONDITIONAL(HAVE_ZLIB, test x$enable_zlibdebuginfo = xyes)
 
 AC_MSG_CHECKING([whether to support UNW_CACHE_PER_THREAD])
 AC_ARG_ENABLE([per-thread-cache],
-AS_HELP_STRING([--enable-per-thread-cache], [build with support for UNW_CACHE_PER_THREAD (which imposes a hight TLS memory usage) (default: disabled)]))
+AS_HELP_STRING([--enable-per-thread-cache], [build with support for UNW_CACHE_PER_THREAD (which imposes a high TLS memory usage) (default: disabled)]))
 AC_MSG_RESULT([$enable_per_thread_cache])
 AS_IF([test x$enable_per_thread_cache = xyes], [
   AC_DEFINE(HAVE___CACHE_PER_THREAD, 1,
diff --git a/doc/libunwind-dynamic.man b/doc/libunwind-dynamic.man
index 3e6875b4..68c66f3a 100644
--- a/doc/libunwind-dynamic.man
+++ b/doc/libunwind-dynamic.man
@@ -13,476 +13,476 @@
 .TH "LIBUNWIND\-DYNAMIC" "3" "29 August 2021" "Programming Library " "Programming Library "
 .SH NAME
 libunwind\-dynamic
-\-\- libunwind\-support for runtime\-generated code 
+\-\- libunwind\-support for runtime\-generated code
 .PP
 .SH INTRODUCTION
 
 .PP
 For libunwind
-to do its job, it needs to be able to reconstruct 
+to do its job, it needs to be able to reconstruct
 the \fIframe state\fP
-of each frame in a call\-chain. The frame state 
-describes the subset of the machine\-state that consists of the 
+of each frame in a call\-chain. The frame state
+describes the subset of the machine\-state that consists of the
 \fIframe registers\fP
-(typically the instruction\-pointer and the 
-stack\-pointer) and all callee\-saved registers (preserved registers). 
-The frame state describes each register either by providing its 
-current value (for frame registers) or by providing the location at 
-which the current value is stored (callee\-saved registers). 
+(typically the instruction\-pointer and the
+stack\-pointer) and all callee\-saved registers (preserved registers).
+The frame state describes each register either by providing its
+current value (for frame registers) or by providing the location at
+which the current value is stored (callee\-saved registers).
 .PP
-For statically generated code, the compiler normally takes care of 
+For statically generated code, the compiler normally takes care of
 emitting \fIunwind\-info\fP
-which provides the minimum amount of 
-information needed to reconstruct the frame\-state for each instruction 
-in a procedure. For dynamically generated code, the runtime code 
-generator must use the dynamic unwind\-info interface provided by 
+which provides the minimum amount of
+information needed to reconstruct the frame\-state for each instruction
+in a procedure. For dynamically generated code, the runtime code
+generator must use the dynamic unwind\-info interface provided by
 libunwind
-to supply the equivalent information. This manual 
-page describes the format of this information in detail. 
+to supply the equivalent information. This manual
+page describes the format of this information in detail.
 .PP
 For the purpose of this discussion, a \fIprocedure\fP
-is defined to 
+is defined to
 be an arbitrary piece of \fIcontiguous\fP
-code. Normally, each 
-procedure directly corresponds to a function in the source\-language 
-but this is not strictly required. For example, a runtime 
-code\-generator could translate a given function into two separate 
-(discontiguous) procedures: one for frequently\-executed (hot) code and 
-one for rarely\-executed (cold) code. Similarly, simple 
-source\-language functions (usually leaf functions) may get translated 
-into code for which the default unwind\-conventions apply and for such 
-code, it is not strictly necessary to register dynamic unwind\-info. 
+code. Normally, each
+procedure directly corresponds to a function in the source\-language
+but this is not strictly required. For example, a runtime
+code\-generator could translate a given function into two separate
+(discontiguous) procedures: one for frequently\-executed (hot) code and
+one for rarely\-executed (cold) code. Similarly, simple
+source\-language functions (usually leaf functions) may get translated
+into code for which the default unwind\-conventions apply and for such
+code, it is not strictly necessary to register dynamic unwind\-info.
 .PP
 A procedure logically consists of a sequence of \fIregions\fP\&.
-Regions are nested in the sense that the frame state at the end of one 
-region is, by default, assumed to be the frame state for the next 
-region. Each region is thought of as being divided into a 
+Regions are nested in the sense that the frame state at the end of one
+region is, by default, assumed to be the frame state for the next
+region. Each region is thought of as being divided into a
 \fIprologue\fP,
 a \fIbody\fP,
 and an \fIepilogue\fP\&.
-Each of them 
-can be empty. If non\-empty, the prologue sets up the frame state for 
-the body. For example, the prologue may need to allocate some space 
-on the stack and save certain callee\-saved registers. The body 
-performs the actual work of the procedure but does not change the 
-frame state in any way. If non\-empty, the epilogue restores the 
-previous frame state and as such it undoes or cancels the effect of 
-the prologue. In fact, a single epilogue may undo the effect of the 
-prologues of several (nested) regions. 
-.PP
-We should point out that even though the prologue, body, and epilogue 
-are logically separate entities, optimizing code\-generators will 
-generally interleave instructions from all three entities. For this 
+Each of them
+can be empty. If non\-empty, the prologue sets up the frame state for
+the body. For example, the prologue may need to allocate some space
+on the stack and save certain callee\-saved registers. The body
+performs the actual work of the procedure but does not change the
+frame state in any way. If non\-empty, the epilogue restores the
+previous frame state and as such it undoes or cancels the effect of
+the prologue. In fact, a single epilogue may undo the effect of the
+prologues of several (nested) regions.
+.PP
+We should point out that even though the prologue, body, and epilogue
+are logically separate entities, optimizing code\-generators will
+generally interleave instructions from all three entities. For this
 reason, the dynamic unwind\-info interface of libunwind
-makes no 
-distinction whatsoever between prologue and body. Similarly, the 
-exact set of instructions that make up an epilogue is also irrelevant. 
-The only point in the epilogue that needs to be described explicitly 
-by the dynamic unwind\-info is the point at which the stack\-pointer 
-gets restored. The reason this point needs to be described is that 
-once the stack\-pointer is restored, all values saved in the 
-deallocated portion of the stack frame become invalid and hence 
+makes no
+distinction whatsoever between prologue and body. Similarly, the
+exact set of instructions that make up an epilogue is also irrelevant.
+The only point in the epilogue that needs to be described explicitly
+by the dynamic unwind\-info is the point at which the stack\-pointer
+gets restored. The reason this point needs to be described is that
+once the stack\-pointer is restored, all values saved in the
+deallocated portion of the stack frame become invalid and hence
 libunwind
-needs to know about it. The portion of the frame 
-state not saved on the stack is assumed to remain valid through the end 
-of the region. For this reason, there is usually no need to describe 
-instructions which restore the contents of callee\-saved registers. 
-.PP
-Within a region, each instruction that affects the frame state in some 
-fashion needs to be described with an operation descriptor. For this 
-purpose, each instruction in the region is assigned a unique index. 
-Exactly how this index is derived depends on the architecture. For 
-example, on RISC and EPIC\-style architecture, instructions have a 
-fixed size so it\&'s possible to simply number the instructions. In 
-contrast, most CISC use variable\-length instruction encodings, so it 
-is usually necessary to use a byte\-offset as the index. Given the 
-instruction index, the operation descriptor specifies the effect of 
-the instruction in an abstract manner. For example, it might express 
-that the instruction stores calle\-saved register r1
-at offset 16 
-in the stack frame. 
+needs to know about it. The portion of the frame
+state not saved on the stack is assumed to remain valid through the end
+of the region. For this reason, there is usually no need to describe
+instructions which restore the contents of callee\-saved registers.
+.PP
+Within a region, each instruction that affects the frame state in some
+fashion needs to be described with an operation descriptor. For this
+purpose, each instruction in the region is assigned a unique index.
+Exactly how this index is derived depends on the architecture. For
+example, on RISC and EPIC\-style architecture, instructions have a
+fixed size so it\&'s possible to simply number the instructions. In
+contrast, most CISC use variable\-length instruction encodings, so it
+is usually necessary to use a byte\-offset as the index. Given the
+instruction index, the operation descriptor specifies the effect of
+the instruction in an abstract manner. For example, it might express
+that the instruction stores callee\-saved register r1
+at offset 16
+in the stack frame.
 .PP
 .SH PROCEDURES
 
 .PP
-A runtime code\-generator registers the dynamic unwind\-info of a 
+A runtime code\-generator registers the dynamic unwind\-info of a
 procedure by setting up a structure of type unw_dyn_info_t
 and calling _U_dyn_register(),
-passing the address of the 
-structure as the sole argument. The members of the 
+passing the address of the
+structure as the sole argument. The members of the
 unw_dyn_info_t
-structure are described below: 
+structure are described below:
 .TP
 void *next
  Private to libunwind\&.
-Must not be used 
-by the application. 
+Must not be used
+by the application.
 .TP
 void *prev
  Private to libunwind\&.
-Must not be used 
-by the application. 
+Must not be used
+by the application.
 .TP
 unw_word_t start_ip
- The start\-address of the 
-instructions of the procedure (remember: procedure are defined to be 
-contiguous pieces of code, so a single code\-range is sufficient). 
+ The start\-address of the
+instructions of the procedure (remember: procedure are defined to be
+contiguous pieces of code, so a single code\-range is sufficient).
 .TP
 unw_word_t end_ip
- The end\-address of the 
-instructions of the procedure (non\-inclusive, that is, 
+ The end\-address of the
+instructions of the procedure (non\-inclusive, that is,
 end_ip\-start_ip
-is the size of the procedure in 
-bytes). 
+is the size of the procedure in
+bytes).
 .TP
 unw_word_t gp
- The global\-pointer value in use 
-for this procedure. The exact meaning of the global\-pointer is 
-architecture\-specific and on some architecture, it is not used at 
-all. 
+ The global\-pointer value in use
+for this procedure. The exact meaning of the global\-pointer is
+architecture\-specific and on some architecture, it is not used at
+all.
 .TP
 int32_t format
- The format of the unwind\-info. 
+ The format of the unwind\-info.
 This member can be one of UNW_INFO_FORMAT_DYNAMIC,
 UNW_INFO_FORMAT_TABLE,
-or 
+or
 UNW_INFO_FORMAT_REMOTE_TABLE\&.
 .TP
 union u
- This union contains one sub\-member 
-structure for every possible unwind\-info format: 
+ This union contains one sub\-member
+structure for every possible unwind\-info format:
 .RS
 .TP
 unw_dyn_proc_info_t pi
- This member is used 
+ This member is used
 for format UNW_INFO_FORMAT_DYNAMIC\&.
 .TP
 unw_dyn_table_info_t ti
- This member is used 
+ This member is used
 for format UNW_INFO_FORMAT_TABLE\&.
 .TP
 unw_dyn_remote_table_info_t rti
- This member 
+ This member
 is used for format UNW_INFO_FORMAT_REMOTE_TABLE\&.
 .RE
 .RS
 .PP
-The format of these sub\-members is described in detail below. 
+The format of these sub\-members is described in detail below.
 .RE
 .PP
 .SS PROC\-INFO FORMAT
 .PP
-This is the preferred dynamic unwind\-info format and it is generally 
-the one used by full\-blown runtime code\-generators. In this format, 
-the details of a procedure are described by a structure of type 
+This is the preferred dynamic unwind\-info format and it is generally
+the one used by full\-blown runtime code\-generators. In this format,
+the details of a procedure are described by a structure of type
 unw_dyn_proc_info_t\&.
-This structure contains the following 
-members: 
+This structure contains the following
+members:
 .PP
 .RE
 .TP
 unw_word_t name_ptr
- The address of a 
-(human\-readable) name of the procedure or 0 if no such name is 
-available. If non\-zero, the string stored at this address must be 
-ASCII NUL terminated. For source languages that use name\-mangling 
-(such as C++ or Java) the string stored at this address should be 
+ The address of a
+(human\-readable) name of the procedure or 0 if no such name is
+available. If non\-zero, the string stored at this address must be
+ASCII NUL terminated. For source languages that use name\-mangling
+(such as C++ or Java) the string stored at this address should be
 the \fIdemangled\fP
-version of the name. 
+version of the name.
 .PP
 .TP
 unw_word_t handler
- The address of the 
-personality\-routine for this procedure. Personality\-routines are 
-used in conjunction with exception handling. See the C++ ABI draft 
-(http://www.codesourcery.com/cxx\-abi/) for an overview and a 
-description of the personality routine. If the procedure has no 
+ The address of the
+personality\-routine for this procedure. Personality\-routines are
+used in conjunction with exception handling. See the C++ ABI draft
+(http://www.codesourcery.com/cxx\-abi/) for an overview and a
+description of the personality routine. If the procedure has no
 personality routine, handler
-must be set to 0. 
+must be set to 0.
 .PP
 .TP
 uint32_t flags
- A bitmask of flags. At the 
-moment, no flags have been defined and this member must be 
-set to 0. 
+ A bitmask of flags. At the
+moment, no flags have been defined and this member must be
+set to 0.
 .PP
 .TP
 unw_dyn_region_info_t *regions
- A NULL\-terminated 
-linked list of region\-descriptors. See section ``Region 
-descriptors\&'' below for more details. 
+ A NULL\-terminated
+linked list of region\-descriptors. See section ``Region
+descriptors\&'' below for more details.
 .PP
 .SS TABLE\-INFO FORMAT
 .PP
-This format is generally used when the dynamically generated code was 
-derived from static code and the unwind\-info for the dynamic and the 
-static versions are identical. For example, this format can be useful 
-when loading statically\-generated code into an address\-space in a 
-non\-standard fashion (i.e., through some means other than 
+This format is generally used when the dynamically generated code was
+derived from static code and the unwind\-info for the dynamic and the
+static versions are identical. For example, this format can be useful
+when loading statically\-generated code into an address\-space in a
+non\-standard fashion (i.e., through some means other than
 dlopen()).
-In this format, the details of a group of procedures 
+In this format, the details of a group of procedures
 is described by a structure of type unw_dyn_table_info\&.
-This structure contains the following members: 
+This structure contains the following members:
 .PP
 .TP
 unw_word_t name_ptr
- The address of a 
-(human\-readable) name of the procedure or 0 if no such name is 
-available. If non\-zero, the string stored at this address must be 
-ASCII NUL terminated. For source languages that use name\-mangling 
-(such as C++ or Java) the string stored at this address should be 
+ The address of a
+(human\-readable) name of the procedure or 0 if no such name is
+available. If non\-zero, the string stored at this address must be
+ASCII NUL terminated. For source languages that use name\-mangling
+(such as C++ or Java) the string stored at this address should be
 the \fIdemangled\fP
-version of the name. 
+version of the name.
 .PP
 .TP
 unw_word_t segbase
- The segment\-base value 
-that needs to be added to the segment\-relative values stored in the 
-unwind\-info. The exact meaning of this value is 
-architecture\-specific. 
+ The segment\-base value
+that needs to be added to the segment\-relative values stored in the
+unwind\-info. The exact meaning of this value is
+architecture\-specific.
 .PP
 .TP
 unw_word_t table_len
- The length of the 
+ The length of the
 unwind\-info (table_data)
-counted in units of words 
+counted in units of words
 (unw_word_t).
 .PP
 .TP
 unw_word_t table_data
- A pointer to the actual 
-data encoding the unwind\-info. The exact format is 
-architecture\-specific (see architecture\-specific sections below). 
+ A pointer to the actual
+data encoding the unwind\-info. The exact format is
+architecture\-specific (see architecture\-specific sections below).
 .PP
 .SS REMOTE TABLE\-INFO FORMAT
 .PP
-The remote table\-info format has the same basic purpose as the regular 
+The remote table\-info format has the same basic purpose as the regular
 table\-info format. The only difference is that when libunwind
-uses the unwind\-info, it will keep the table data in the target 
-address\-space (which may be remote). Consequently, the type of the 
+uses the unwind\-info, it will keep the table data in the target
+address\-space (which may be remote). Consequently, the type of the
 table_data
 member is unw_word_t
-rather than a pointer. 
+rather than a pointer.
 This implies that libunwind
-will have to access the table\-data 
+will have to access the table\-data
 via the address\-space\&'s access_mem()
-call\-back, rather than 
-through a direct memory reference. 
-.PP
-From the point of view of a runtime\-code generator, the remote 
-table\-info format offers no advantage and it is expected that such 
-generators will describe their procedures either with the proc\-info 
-format or the normal table\-info format. The main reason that the 
-remote table\-info format exists is to enable the 
+call\-back, rather than
+through a direct memory reference.
+.PP
+From the point of view of a runtime\-code generator, the remote
+table\-info format offers no advantage and it is expected that such
+generators will describe their procedures either with the proc\-info
+format or the normal table\-info format. The main reason that the
+remote table\-info format exists is to enable the
 address\-space\-specific find_proc_info()
-callback (see 
+callback (see
 unw_create_addr_space(3))
-to return unwind tables whose 
-data remains in remote memory. This can speed up unwinding (e.g., for 
-a debugger) because it reduces the amount of data that needs to be 
-loaded from remote memory. 
+to return unwind tables whose
+data remains in remote memory. This can speed up unwinding (e.g., for
+a debugger) because it reduces the amount of data that needs to be
+loaded from remote memory.
 .PP
 .SH REGIONS DESCRIPTORS
 
 .PP
-A region descriptor is a variable length structure that describes how 
-each instruction in the region affects the frame state. Of course, 
-most instructions in a region usually do not change the frame state and 
-for those, nothing needs to be recorded in the region descriptor. A 
-region descriptor is a structure of type 
+A region descriptor is a variable length structure that describes how
+each instruction in the region affects the frame state. Of course,
+most instructions in a region usually do not change the frame state and
+for those, nothing needs to be recorded in the region descriptor. A
+region descriptor is a structure of type
 unw_dyn_region_info_t
-and has the following members: 
+and has the following members:
 .TP
 unw_dyn_region_info_t *next
- A pointer to the 
+ A pointer to the
 next region. If this is the last region, next
 is NULL\&.
 .TP
 int32_t insn_count
- The length of the region in 
-instructions. Each instruction is assumed to have a fixed size (see 
-architecture\-specific sections for details). The value of 
+ The length of the region in
+instructions. Each instruction is assumed to have a fixed size (see
+architecture\-specific sections for details). The value of
 insn_count
-may be negative in the last region of a procedure 
+may be negative in the last region of a procedure
 (i.e., it may be negative only if next
 is NULL).
-A 
+A
 negative value indicates that the region covers the last \fIN\fP
 instructions of the procedure, where \fIN\fP
-is the absolute value 
+is the absolute value
 of insn_count\&.
 .TP
 uint32_t op_count
- The (allocated) length of 
+ The (allocated) length of
 the op_count
-array. 
+array.
 .TP
 unw_dyn_op_t op
- An array of dynamic unwind 
-directives. See Section ``Dynamic unwind directives\&'' for a 
-description of the directives. 
+ An array of dynamic unwind
+directives. See Section ``Dynamic unwind directives\&'' for a
+description of the directives.
 .PP
 A region descriptor with an insn_count
-of zero is an 
+of zero is an
 \fIempty region\fP
-and such regions are perfectly legal. In fact, 
-empty regions can be useful to establish a particular frame state 
-before the start of another region. 
-.PP
-A single region list can be shared across multiple procedures provided 
-those procedures share a common prologue and epilogue (their bodies 
-may differ, of course). Normally, such procedures consist of a canned 
-prologue, the body, and a canned epilogue. This could be described by 
-two regions: one covering the prologue and one covering the epilogue. 
-Since the body length is variable, the latter region would need to 
+and such regions are perfectly legal. In fact,
+empty regions can be useful to establish a particular frame state
+before the start of another region.
+.PP
+A single region list can be shared across multiple procedures provided
+those procedures share a common prologue and epilogue (their bodies
+may differ, of course). Normally, such procedures consist of a canned
+prologue, the body, and a canned epilogue. This could be described by
+two regions: one covering the prologue and one covering the epilogue.
+Since the body length is variable, the latter region would need to
 specify a negative value in insn_count
-such that 
+such that
 libunwind
-knows that the region covers the end of the procedure 
+knows that the region covers the end of the procedure
 (up to the address specified by end_ip).
 .PP
-The region descriptor is a variable length structure to make it 
-possible to allocate all the necessary memory with a single 
-memory\-allocation request. To facilitate the allocation of a region 
+The region descriptor is a variable length structure to make it
+possible to allocate all the necessary memory with a single
+memory\-allocation request. To facilitate the allocation of a region
 descriptors libunwind
-provides a helper routine with the 
-following synopsis: 
+provides a helper routine with the
+following synopsis:
 .PP
 size_t
 _U_dyn_region_size(int
 op_count);
 .PP
-This routine returns the number of bytes needed to hold a region 
+This routine returns the number of bytes needed to hold a region
 descriptor with space for op_count
-unwind directives. Note 
+unwind directives. Note
 that the length of the op
-array does not have to match exactly 
-with the number of directives in a region. Instead, it is sufficient 
+array does not have to match exactly
+with the number of directives in a region. Instead, it is sufficient
 if the op
-array contains at least as many entries as there are 
-directives, since the end of the directives can always be indicated 
+array contains at least as many entries as there are
+directives, since the end of the directives can always be indicated
 with the UNW_DYN_STOP
-directive. 
+directive.
 .PP
 .SH DYNAMIC UNWIND DIRECTIVES
 
 .PP
-A dynamic unwind directive describes how the frame state changes 
-at a particular point within a region. The description is in 
+A dynamic unwind directive describes how the frame state changes
+at a particular point within a region. The description is in
 the form of a structure of type unw_dyn_op_t\&.
-This 
-structure has the following members: 
+This
+structure has the following members:
 .TP
 int8_t tag
- The operation tag. Must be one 
+ The operation tag. Must be one
 of the unw_dyn_operation_t
-values described below. 
+values described below.
 .TP
 int8_t qp
- The qualifying predicate that controls 
-whether or not this directive is active. This is useful for 
-predicated architectures such as IA\-64 or ARM, where the contents of 
-another (callee\-saved) register determines whether or not an 
-instruction is executed (takes effect). If the directive is always 
-active, this member should be set to the manifest constant 
+ The qualifying predicate that controls
+whether or not this directive is active. This is useful for
+predicated architectures such as IA\-64 or ARM, where the contents of
+another (callee\-saved) register determines whether or not an
+instruction is executed (takes effect). If the directive is always
+active, this member should be set to the manifest constant
 _U_QP_TRUE
-(this constant is defined for all 
-architectures, predicated or not). 
+(this constant is defined for all
+architectures, predicated or not).
 .TP
 int16_t reg
- The number of the register affected 
-by the instruction. 
+ The number of the register affected
+by the instruction.
 .TP
 int32_t when
- The region\-relative number of 
-the instruction to which this directive applies. For example, 
-a value of 0 means that the effect described by this directive 
-has taken place once the first instruction in the region has 
-executed. 
+ The region\-relative number of
+the instruction to which this directive applies. For example,
+a value of 0 means that the effect described by this directive
+has taken place once the first instruction in the region has
+executed.
 .TP
 unw_word_t val
- The value to be applied by the 
-operation tag. The exact meaning of this value varies by tag. See 
-Section ``Operation tags\&'' below. 
+ The value to be applied by the
+operation tag. The exact meaning of this value varies by tag. See
+Section ``Operation tags\&'' below.
 .PP
-It is perfectly legitimate to specify multiple dynamic unwind 
+It is perfectly legitimate to specify multiple dynamic unwind
 directives with the same when
-value, if a particular instruction 
-has a complex effect on the frame state. 
+value, if a particular instruction
+has a complex effect on the frame state.
 .PP
-Empty regions by definition contain no actual instructions and as such 
-the directives are not tied to a particular instruction. By 
+Empty regions by definition contain no actual instructions and as such
+the directives are not tied to a particular instruction. By
 convention, the when
-member should be set to 0, however. 
+member should be set to 0, however.
 .PP
-There is no need for the dynamic unwind directives to appear 
+There is no need for the dynamic unwind directives to appear
 in order of increasing when
-values. If the directives happen to 
-be sorted in that order, it may result in slightly faster execution, 
-but a runtime code\-generator should not go to extra lengths just to 
-ensure that the directives are sorted. 
+values. If the directives happen to
+be sorted in that order, it may result in slightly faster execution,
+but a runtime code\-generator should not go to extra lengths just to
+ensure that the directives are sorted.
 .PP
 IMPLEMENTATION NOTE: should libunwind
-implementations for 
-certain architectures prefer the list of unwind directives to be 
-sorted, it is recommended that such implementations first check 
-whether the list happens to be sorted already and, if not, sort the 
-directives explicitly before the first use. With this approach, the 
-overhead of explicit sorting is only paid when there is a real benefit 
-and if the runtime code\-generator happens to generate sorted lists 
-naturally, the performance penalty is limited to a simple O(N) check. 
+implementations for
+certain architectures prefer the list of unwind directives to be
+sorted, it is recommended that such implementations first check
+whether the list happens to be sorted already and, if not, sort the
+directives explicitly before the first use. With this approach, the
+overhead of explicit sorting is only paid when there is a real benefit
+and if the runtime code\-generator happens to generate sorted lists
+naturally, the performance penalty is limited to a simple O(N) check.
 .PP
 .SS OPERATIONS TAGS
 .PP
-The possible operation tags are defined by enumeration type 
+The possible operation tags are defined by enumeration type
 unw_dyn_operation_t
-which defines the following 
-values: 
+which defines the following
+values:
 .PP
 .TP
 UNW_DYN_STOP
- Marks the end of the dynamic unwind 
+ Marks the end of the dynamic unwind
 directive list. All remaining entries in the op
-array of the 
-region\-descriptor are ignored. This tag is guaranteed to have a 
-value of 0. 
+array of the
+region\-descriptor are ignored. This tag is guaranteed to have a
+value of 0.
 .PP
 .TP
 UNW_DYN_SAVE_REG
- Marks an instruction which saves 
+ Marks an instruction which saves
 register reg
 to register val\&.
 .PP
 .TP
 UNW_DYN_SPILL_FP_REL
- Marks an instruction which 
+ Marks an instruction which
 spills register reg
-to a frame\-pointer\-relative location. The 
-frame\-pointer\-relative offset is given by the value stored in member 
+to a frame\-pointer\-relative location. The
+frame\-pointer\-relative offset is given by the value stored in member
 val\&.
-See the architecture\-specific sections for a description 
-of the stack frame layout. 
+See the architecture\-specific sections for a description
+of the stack frame layout.
 .PP
 .TP
 UNW_DYN_SPILL_SP_REL
- Marks an instruction which 
+ Marks an instruction which
 spills register reg
-to a stack\-pointer\-relative location. The 
-stack\-pointer\-relative offset is given by the value stored in member 
+to a stack\-pointer\-relative location. The
+stack\-pointer\-relative offset is given by the value stored in member
 val\&.
-See the architecture\-specific sections for a description 
-of the stack frame layout. 
+See the architecture\-specific sections for a description
+of the stack frame layout.
 .PP
 .TP
 UNW_DYN_ADD
- Marks an instruction which adds 
+ Marks an instruction which adds
 the constant value val
 to register reg\&.
-To add subtract 
-a constant value, store the two\&'s\-complement of the value in 
+To add subtract
+a constant value, store the two\&'s\-complement of the value in
 val\&.
-The set of registers that can be specified for this tag 
-is described in the architecture\-specific sections below. 
+The set of registers that can be specified for this tag
+is described in the architecture\-specific sections below.
 .PP
 .TP
 UNW_DYN_POP_FRAMES
@@ -496,29 +496,29 @@ UNW_DYN_COPY_STATE
 .TP
 UNW_DYN_ALIAS
  .PP
-unw_dyn_op_t 
-.PP
-_U_dyn_op_save_reg(); 
-_U_dyn_op_spill_fp_rel(); 
-_U_dyn_op_spill_sp_rel(); 
-_U_dyn_op_add(); 
-_U_dyn_op_pop_frames(); 
-_U_dyn_op_label_state(); 
-_U_dyn_op_copy_state(); 
-_U_dyn_op_alias(); 
-_U_dyn_op_stop(); 
+unw_dyn_op_t
+.PP
+_U_dyn_op_save_reg();
+_U_dyn_op_spill_fp_rel();
+_U_dyn_op_spill_sp_rel();
+_U_dyn_op_add();
+_U_dyn_op_pop_frames();
+_U_dyn_op_label_state();
+_U_dyn_op_copy_state();
+_U_dyn_op_alias();
+_U_dyn_op_stop();
 .PP
 .SH IA\-64 SPECIFICS
 
 .PP
-\- meaning of segbase member in table\-info/table\-remote\-info format 
-\- format of table_data in table\-info/table\-remote\-info format 
-\- instruction size: each bundle is counted as 3 instructions, regardless 
-of template (MLX) 
-\- describe stack\-frame layout, especially with regards to sp\-relative 
-and fp\-relative addressing 
-\- UNW_DYN_ADD can only add to ``sp\&'' (always a negative value); use 
-POP_FRAMES otherwise 
+\- meaning of segbase member in table\-info/table\-remote\-info format
+\- format of table_data in table\-info/table\-remote\-info format
+\- instruction size: each bundle is counted as 3 instructions, regardless
+of template (MLX)
+\- describe stack\-frame layout, especially with regards to sp\-relative
+and fp\-relative addressing
+\- UNW_DYN_ADD can only add to ``sp\&'' (always a negative value); use
+POP_FRAMES otherwise
 .PP
 .SH SEE ALSO
 
diff --git a/doc/libunwind-dynamic.tex b/doc/libunwind-dynamic.tex
index f3258921..a3b7762b 100644
--- a/doc/libunwind-dynamic.tex
+++ b/doc/libunwind-dynamic.tex
@@ -78,7 +78,7 @@ contrast, most CISC use variable-length instruction encodings, so it
 is usually necessary to use a byte-offset as the index.  Given the
 instruction index, the operation descriptor specifies the effect of
 the instruction in an abstract manner.  For example, it might express
-that the instruction stores calle-saved register \Var{r1} at offset 16
+that the instruction stores callee-saved register \Var{r1} at offset 16
 in the stack frame.
 
 \section{Procedures}
diff --git a/doc/unw_get_proc_name_by_ip.man b/doc/unw_get_proc_name_by_ip.man
index 26c533ce..70b10aae 100644
--- a/doc/unw_get_proc_name_by_ip.man
+++ b/doc/unw_get_proc_name_by_ip.man
@@ -13,7 +13,7 @@
 .TH "UNW\\_GET\\_PROC\\_NAME\\_BY\\_IP" "3" "30 August 2021" "Programming Library " "Programming Library "
 .SH NAME
 unw_get_proc_name_by_ip
-\-\- get procedure name 
+\-\- get procedure name
 .PP
 .SH SYNOPSIS
 
@@ -35,89 +35,89 @@ void *arg);
 
 .PP
 The unw_get_proc_name_by_ip()
-routine returns the name of 
+routine returns the name of
 a procedure just like unw_get_proc_name(),
-except that the 
-name is looked up by instruction\-pointer (IP) instead of a cursor. 
+except that the
+name is looked up by instruction\-pointer (IP) instead of a cursor.
 .PP
 The routine expects the following arguments: as
-is the 
-address\-space in which the instruction\-pointer should be looked up. 
-For a look\-up in the local address\-space, 
+is the
+address\-space in which the instruction\-pointer should be looked up.
+For a look\-up in the local address\-space,
 unw_local_addr_space
-can be passed for this argument. 
+can be passed for this argument.
 Argument ip
-is the instruction\-pointer for which the procedure 
+is the instruction\-pointer for which the procedure
 name should be looked up. The bufp
-argument is a pointer to 
+argument is a pointer to
 a character buffer that is at least len
-bytes long. This buffer 
+bytes long. This buffer
 is used to return the name of the procedure. The offp
-argument 
-is a pointer to a word that is used to return the byte\-offset of the 
-instruction\-pointer relative to the start of the procedure. 
+argument
+is a pointer to a word that is used to return the byte\-offset of the
+instruction\-pointer relative to the start of the procedure.
 Lastly, arg
-is the address\-space argument that should be used 
-when accessing the address\-space. It has the same purpose as the 
+is the address\-space argument that should be used
+when accessing the address\-space. It has the same purpose as the
 argument of the same name for unw_init_remote().
-When 
-accessing the local address\-space (first argument is 
+When
+accessing the local address\-space (first argument is
 unw_local_addr_space),
 NULL
-must be passed for this 
-argument. 
-.PP
-Note that on some platforms there is no reliable way to distinguish 
-between procedure names and ordinary labels. Furthermore, if symbol 
-information has been stripped from a program, procedure names may be 
-completely unavailable or may be limited to those exported via a 
-dynamic symbol table. In such cases, 
+must be passed for this
+argument.
+.PP
+Note that on some platforms there is no reliable way to distinguish
+between procedure names and ordinary labels. Furthermore, if symbol
+information has been stripped from a program, procedure names may be
+completely unavailable or may be limited to those exported via a
+dynamic symbol table. In such cases,
 unw_get_proc_name_by_ip()
-may return the name of a label 
-or a preceeding (nearby) procedure. However, the offset returned 
+may return the name of a label
+or a preceding (nearby) procedure. However, the offset returned
 through offp
-is always relative to the returned name, which 
-ensures that the value (address) of the returned name plus the 
-returned offset will always be equal to the instruction\-pointer 
+is always relative to the returned name, which
+ensures that the value (address) of the returned name plus the
+returned offset will always be equal to the instruction\-pointer
 ip\&.
 .PP
 .SH RETURN VALUE
 
 .PP
 On successful completion, unw_get_proc_name_by_ip()
-returns 0. Otherwise the negative value of one of the error\-codes 
-below is returned. 
+returns 0. Otherwise the negative value of one of the error\-codes
+below is returned.
 .PP
 .SH THREAD AND SIGNAL SAFETY
 
 .PP
 unw_get_proc_name_by_ip()
-is thread\-safe. If the local 
+is thread\-safe. If the local
 address\-space is passed in argument as,
-this routine is also 
-safe to use from a signal handler. 
+this routine is also
+safe to use from a signal handler.
 .PP
 .SH ERRORS
 
 .PP
 .TP
 UNW_EUNSPEC
- An unspecified error occurred. 
+ An unspecified error occurred.
 .TP
 UNW_ENOINFO
  Libunwind
-was unable to determine 
-the name of the procedure. 
+was unable to determine
+the name of the procedure.
 .TP
 UNW_ENOMEM
- The procedure name is too long to fit 
-in the buffer provided. A truncated version of the name has been 
-returned. 
+ The procedure name is too long to fit
+in the buffer provided. A truncated version of the name has been
+returned.
 .PP
 In addition, unw_get_proc_name_by_ip()
-may return any error 
+may return any error
 returned by the access_mem()
-call\-back (see 
+call\-back (see
 unw_create_addr_space(3)).
 .PP
 .SH SEE ALSO
diff --git a/doc/unw_get_proc_name_by_ip.tex b/doc/unw_get_proc_name_by_ip.tex
index 4f46690f..cb597680 100644
--- a/doc/unw_get_proc_name_by_ip.tex
+++ b/doc/unw_get_proc_name_by_ip.tex
@@ -43,7 +43,7 @@ information has been stripped from a program, procedure names may be
 completely unavailable or may be limited to those exported via a
 dynamic symbol table.  In such cases,
 \Func{unw\_get\_proc\_name\_by\_ip}() may return the name of a label
-or a preceeding (nearby) procedure.  However, the offset returned
+or a preceding (nearby) procedure.  However, the offset returned
 through \Var{offp} is always relative to the returned name, which
 ensures that the value (address) of the returned name plus the
 returned offset will always be equal to the instruction-pointer
diff --git a/include/libunwind_i.h b/include/libunwind_i.h
index bcf22956..83561240 100644
--- a/include/libunwind_i.h
+++ b/include/libunwind_i.h
@@ -172,7 +172,7 @@ target_is_big_endian()
 
 /* Type of a mask that can be used to inhibit preemption.  At the
    userlevel, preemption is caused by signals and hence sigset_t is
-   appropriate.  In constrast, the Linux kernel uses "unsigned long"
+   appropriate.  In contrast, the Linux kernel uses "unsigned long"
    to hold the processor "flags" instead.  */
 typedef sigset_t intrmask_t;
 
diff --git a/include/remote/freebsd-elf_common.h b/include/remote/freebsd-elf_common.h
index cc780208..b53ffdc8 100644
--- a/include/remote/freebsd-elf_common.h
+++ b/include/remote/freebsd-elf_common.h
@@ -627,7 +627,7 @@ typedef struct {
 #define	R_IA_64_PCREL22		0x7a	/* immediate22	S + A - P */
 #define	R_IA_64_PCREL64I	0x7b	/* immediate64	S + A - P */
 #define	R_IA_64_IPLTMSB		0x80	/* function descriptor MSB special */
-#define	R_IA_64_IPLTLSB		0x81	/* function descriptor LSB speciaal */
+#define	R_IA_64_IPLTLSB		0x81	/* function descriptor LSB special */
 #define	R_IA_64_SUB		0x85	/* immediate64	A - S */
 #define	R_IA_64_LTOFF22X	0x86	/* immediate22	special */
 #define	R_IA_64_LDXMOV		0x87	/* immediate22	special */
diff --git a/include/tdep-ia64/libunwind_i.h b/include/tdep-ia64/libunwind_i.h
index 8cb8fea2..5b0defc8 100644
--- a/include/tdep-ia64/libunwind_i.h
+++ b/include/tdep-ia64/libunwind_i.h
@@ -152,7 +152,7 @@ struct cursor
     unsigned int pi_is_dynamic :1; /* proc_info found via dynamic proc info? */
     unw_proc_info_t pi;         /* info about current procedure */
 
-    /* In case of stack-discontiguities, such as those introduced by
+    /* In case of stack discontiguities, such as those introduced by
        signal-delivery on an alternate signal-stack (see
        sigaltstack(2)), we use the following data-structure to keep
        track of the register-backing-store areas across on which the
diff --git a/src/coredump/_UCD_get_mapinfo_linux.c b/src/coredump/_UCD_get_mapinfo_linux.c
index ac2df590..0d04f01a 100644
--- a/src/coredump/_UCD_get_mapinfo_linux.c
+++ b/src/coredump/_UCD_get_mapinfo_linux.c
@@ -70,7 +70,7 @@ static const size_t mapinfo_offset = sizeof (core_nt_file_hdr_t);
  * @param[in] arg   The user-supplied callback argument
  *
  * The CORE/NT_FILE note type contains a list of start/end virtual addresses
- * within the core file and an associated filename. The purpose is to mape
+ * within the core file and an associated filename. The purpose is to map
  * various segments loaded into memory from ELF files with the ELF file from
  * which those segments were loaded.
  *
diff --git a/src/coredump/ucd_file_table.c b/src/coredump/ucd_file_table.c
index e6d966be..15e07047 100644
--- a/src/coredump/ucd_file_table.c
+++ b/src/coredump/ucd_file_table.c
@@ -40,7 +40,7 @@
  *
  * Stores the filename in the object and sets the fd to an uninitialized state.
  *
- * @returns UNW_ESUCCESS on success, a negated `unw_erro_t` code otherwise.
+ * @returns UNW_ESUCCESS on success, a negated `unw_error_t` code otherwise.
  */
 unw_error_t
 ucd_file_init (ucd_file_t *ucd_file, char const *filename)
@@ -156,7 +156,7 @@ ucd_file_unmap (ucd_file_t *ucd_file)
  * Initialize a UCD file table.
  * @param[in] ucd_file_table  The UCD file table to initialize.
  *
- * @returns UNW_ESUCCESS on success, a negated `unw_erro_t` code otherwise.
+ * @returns UNW_ESUCCESS on success, a negated `unw_error_t` code otherwise.
  */
 unw_error_t
 ucd_file_table_init (ucd_file_table_t *ucd_file_table)
diff --git a/src/dwarf/Gexpr.c b/src/dwarf/Gexpr.c
index 977c5593..c510795b 100644
--- a/src/dwarf/Gexpr.c
+++ b/src/dwarf/Gexpr.c
@@ -265,7 +265,7 @@ if (stackerror)                                 \
     return -UNW_EINVAL;                         \
   }
 
-// Removed the parentheses on the asignment
+// Removed the parentheses on the assignment
 // to allow the extra stack error check
 // when x is evaluated
 # define push(x)                                \
diff --git a/src/dwarf/Gfde.c b/src/dwarf/Gfde.c
index 3d3edaac..3847d0a0 100644
--- a/src/dwarf/Gfde.c
+++ b/src/dwarf/Gfde.c
@@ -141,10 +141,10 @@ parse_cie (unw_addr_space_t as, unw_accessors_t *a, unw_word_t addr,
 
   if (version > 3)
     {
-      if((ret = dwarf_readu8(as, a, &addr, &address_size, arg)) < 0) 
+      if((ret = dwarf_readu8(as, a, &addr, &address_size, arg)) < 0)
 	return ret;
 
-      if((ret = dwarf_readu8(as, a, &addr, &segment_size, arg)) < 0) 
+      if((ret = dwarf_readu8(as, a, &addr, &segment_size, arg)) < 0)
 	return ret;
     }
 
@@ -223,8 +223,8 @@ parse_cie (unw_addr_space_t as, unw_accessors_t *a, unw_word_t addr,
   return 0;
 }
 
-/* Extract proc-info from the FDE starting at adress ADDR.
-   
+/* Extract proc-info from the FDE starting at address ADDR.
+
    Pass BASE as zero for eh_frame behaviour, or a pointer to
    debug_frame base for debug_frame behaviour.  */
 
diff --git a/src/dwarf/Gfind_proc_info-lsb.c b/src/dwarf/Gfind_proc_info-lsb.c
index 8274733e..196cfca3 100644
--- a/src/dwarf/Gfind_proc_info-lsb.c
+++ b/src/dwarf/Gfind_proc_info-lsb.c
@@ -658,7 +658,7 @@ dwarf_callback (struct dl_phdr_info *info, size_t size, void *ptr)
     {
       if (p_dynamic)
         {
-          /* For dynamicly linked executables and shared libraries,
+          /* For dynamically linked executables and shared libraries,
              DT_PLTGOT is the value that data-relative addresses are
              relative to for that object.  We call this the "gp".  */
           Elf_W(Dyn) *dyn = (Elf_W(Dyn) *)(p_dynamic->p_vaddr + load_base);
diff --git a/src/dwarf/Gfind_unwind_table.c b/src/dwarf/Gfind_unwind_table.c
index 4942b34f..ad9b4e9a 100644
--- a/src/dwarf/Gfind_unwind_table.c
+++ b/src/dwarf/Gfind_unwind_table.c
@@ -50,7 +50,7 @@ dwarf_find_unwind_table (struct elf_dyn_info *edi, unw_addr_space_t as,
   unw_accessors_t *a;
   Elf_W(Ehdr) *ehdr;
 #if UNW_TARGET_ARM
-  const Elf_W(Phdr) *parm_exidx = NULL;
+  const Elf_W(Phdr) *param_exidx = NULL;
 #endif
   int i, ret, found = 0;
 
@@ -92,7 +92,7 @@ dwarf_find_unwind_table (struct elf_dyn_info *edi, unw_addr_space_t as,
 
 #if UNW_TARGET_ARM
         case PT_ARM_EXIDX:
-          parm_exidx = phdr + i;
+          param_exidx = phdr + i;
           break;
 #endif
 
@@ -112,7 +112,7 @@ dwarf_find_unwind_table (struct elf_dyn_info *edi, unw_addr_space_t as,
     {
       if (pdyn)
         {
-          /* For dynamicly linked executables and shared libraries,
+          /* For dynamically linked executables and shared libraries,
              DT_PLTGOT is the value that data-relative addresses are
              relative to for that object.  We call this the "gp".  */
                 Elf_W(Dyn) *dyn = (Elf_W(Dyn) *)(pdyn->p_offset
@@ -212,14 +212,14 @@ dwarf_find_unwind_table (struct elf_dyn_info *edi, unw_addr_space_t as,
     }
 
 #if UNW_TARGET_ARM
-  if (parm_exidx)
+  if (param_exidx)
     {
       edi->di_arm.format = UNW_INFO_FORMAT_ARM_EXIDX;
       edi->di_arm.start_ip = start_ip;
       edi->di_arm.end_ip = end_ip;
       edi->di_arm.u.rti.name_ptr = to_unw_word (path);
-      edi->di_arm.u.rti.table_data = load_base + parm_exidx->p_vaddr;
-      edi->di_arm.u.rti.table_len = parm_exidx->p_memsz;
+      edi->di_arm.u.rti.table_data = load_base + param_exidx->p_vaddr;
+      edi->di_arm.u.rti.table_len = param_exidx->p_memsz;
       found = 1;
     }
 #endif
diff --git a/src/elfxx.c b/src/elfxx.c
index 321cfb97..2f9d1593 100644
--- a/src/elfxx.c
+++ b/src/elfxx.c
@@ -165,7 +165,7 @@ elf_w (get_load_offset) (struct elf_image *ei, unsigned long segbase,
   Elf_W (Ehdr) *ehdr;
   Elf_W (Phdr) *phdr;
   int i;
-  // mapoff is obtained from mmap informations, so is always aligned on a page size.
+  // mapoff is obtained from mmap information, so it is always aligned on a page size.
   // PT_LOAD program headers p_offset however is not guaranteed to be aligned on a
   // page size, ld.lld generate libraries where this is not the case. So we must
   // make sure we compare both values with the same alignment.
diff --git a/src/ia64/Gscript.c b/src/ia64/Gscript.c
index ea5ac15f..1af6a855 100644
--- a/src/ia64/Gscript.c
+++ b/src/ia64/Gscript.c
@@ -287,7 +287,7 @@ compile_reg (struct ia64_state_record *sr, int i, struct ia64_reg_info *r,
         {
         case IA64_WHERE_FR:
           /* Note: There is no need to handle NaT-bit info here
-             (indepent of is_preserved_gr), because for floating-point
+             (independent of is_preserved_gr), because for floating-point
              NaTs are represented as NaTVal, so the NaT-info never
              needs to be consulated.  */
           if (rval >= 2 && rval <= 5)
diff --git a/src/ia64/Gtables.c b/src/ia64/Gtables.c
index f5e8f2d8..e6ac5197 100644
--- a/src/ia64/Gtables.c
+++ b/src/ia64/Gtables.c
@@ -531,7 +531,7 @@ callback (struct dl_phdr_info *info, size_t size, void *ptr)
 
   if (p_dynamic)
     {
-      /* For dynamicly linked executables and shared libraries,
+      /* For dynamically linked executables and shared libraries,
          DT_PLTGOT is the gp value for that object.  */
       Elf64_Dyn *dyn = (Elf64_Dyn *)(p_dynamic->p_vaddr + load_base);
       for (; dyn->d_tag != DT_NULL; ++dyn)
diff --git a/src/ppc32/init.h b/src/ppc32/init.h
index 87a69b14..17650d7a 100644
--- a/src/ppc32/init.h
+++ b/src/ppc32/init.h
@@ -27,7 +27,7 @@ WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.  */
 
 #include "unwind_i.h"
 
-/* Here is the "common" init, for remote and local debuging" */
+/* Here is the "common" init, for remote and local debugging" */
 
 static inline int
 common_init_ppc32 (struct cursor *c, unsigned use_prev_instr)
diff --git a/src/tilegx/Gstep.c b/src/tilegx/Gstep.c
index c748dbc5..b4456897 100644
--- a/src/tilegx/Gstep.c
+++ b/src/tilegx/Gstep.c
@@ -35,7 +35,7 @@ unw_step (unw_cursor_t *cursor)
   Debug (1, "(cursor=%p, ip=0x%016lx, sp=0x%016lx)\n",
          c, c->dwarf.ip, c->dwarf.cfa);
 
-  /* Special handling the singal frame. */
+  /* Special handling the signal frame. */
   if (unw_is_signal_frame (cursor) > 0)
     return tilegx_handle_signal_frame (cursor);
 
diff --git a/src/x86_64/Gstash_frame.c b/src/x86_64/Gstash_frame.c
index 2a44f873..d8f086e9 100644
--- a/src/x86_64/Gstash_frame.c
+++ b/src/x86_64/Gstash_frame.c
@@ -45,7 +45,7 @@ tdep_stash_frame (struct dwarf_cursor *d, struct dwarf_reg_state *rs)
     rs->reg.where[RBP] == DWARF_WHERE_EXPR) {
     /* Check for GCC generated alignment frame for rsp.  A simple
      * def_cfa_expr that loads a constant offset from rbp, where the
-     * addres of the rip was pushed on the stack */
+     * address of the rip was pushed on the stack */
     unw_word_t cfa_addr = rs->reg.val[DWARF_CFA_REG_COLUMN];
     unw_word_t rbp_addr = rs->reg.val[RBP];
     unw_word_t cfa_offset;
diff --git a/tests/crasher.c b/tests/crasher.c
index bb99e339..e19e2d69 100644
--- a/tests/crasher.c
+++ b/tests/crasher.c
@@ -88,7 +88,7 @@ write_maps(char *fname)
 
 #ifdef __GNUC__
 #ifndef __clang__
-// Gcc >= 8 became too good at inlining aliase c into b when using -O2 or -O3,
+// Gcc >= 8 became too good at inlining alias c into b when using -O2 or -O3,
 // so force -O1 in all cases, otherwise a frame will be missing in the tests.
 #pragma GCC optimize "-O1"
 #endif
@@ -110,7 +110,7 @@ int NOINLINE b(int x)
   int r;
 
   compiler_barrier();
-  
+
   if (x)
     r = a();
   else
diff --git a/tests/x64-test-dwarf-expressions.S b/tests/x64-test-dwarf-expressions.S
index f275625d..19ebc9d4 100644
--- a/tests/x64-test-dwarf-expressions.S
+++ b/tests/x64-test-dwarf-expressions.S
@@ -64,7 +64,7 @@ DW_CFA_expression_inner:
   # DW_CFA_expression(0x10), r12(0x0c), Length(0x02),        (preamble)
   # DW_OP_lit16(0x40), DW_OP_minus(0x1c)                     (instructions)
   # Parsing starts with the CFA on the stack, then pushes 16, then does a minus
-  # which is eqivalent to a=pop(), b=pop(), push(b-a), leaving us with a value
+  # which is equivalent to a=pop(), b=pop(), push(b-a), leaving us with a value
   # of cfa-16 (cfa points at old rsp, cfa-8 is our rip, so we stored r12 at
   # cfa-16).
   xor %r12, %r12                             # Trash r12