From 14e199e1f2edeecc5789e3ce10dbd5de7fd86441 Mon Sep 17 00:00:00 2001 From: Adeel Mujahid <3840695+am11@users.noreply.github.com> Date: Fri, 5 Aug 2022 03:14:42 +0300 Subject: Fix typos (#397) * Fix typos * Cleanup trailing whitespaces in committed files * Update include/tdep-ia64/libunwind_i.h --- NEWS | 26 +- configure.ac | 2 +- doc/libunwind-dynamic.man | 572 +++++++++++++++++----------------- doc/libunwind-dynamic.tex | 2 +- doc/unw_get_proc_name_by_ip.man | 88 +++--- doc/unw_get_proc_name_by_ip.tex | 2 +- include/libunwind_i.h | 2 +- include/remote/freebsd-elf_common.h | 2 +- include/tdep-ia64/libunwind_i.h | 2 +- src/coredump/_UCD_get_mapinfo_linux.c | 2 +- src/coredump/ucd_file_table.c | 4 +- src/dwarf/Gexpr.c | 2 +- src/dwarf/Gfde.c | 8 +- src/dwarf/Gfind_proc_info-lsb.c | 2 +- src/dwarf/Gfind_unwind_table.c | 12 +- src/elfxx.c | 2 +- src/ia64/Gscript.c | 2 +- src/ia64/Gtables.c | 2 +- src/ppc32/init.h | 2 +- src/tilegx/Gstep.c | 2 +- src/x86_64/Gstash_frame.c | 2 +- tests/crasher.c | 4 +- tests/x64-test-dwarf-expressions.S | 2 +- 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 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 -- cgit v1.2.1