dos2unix AMDGPUDwarfExtensionAllowLocationDescriptionOnTheDwarfExpressionStack.md

llvm/docs/AMDGPUDwarfExtensionAllowLocationDescriptionOnTheDwarfExpressionStack/AMDGPUDwarfExtensionAllowLocationDescriptionOnTheDwarfExpressionStack.md

-# Allow Location Descriptions on the DWARF Expression Stack <!-- omit in toc -->
-
-- [1. Extension](#extension)
-- [2. Heterogeneous Computing Devices](#heterogeneous-computing-devices)
-- [3. DWARF 5](#dwarf-5)
-  - [3.1 How DWARF Maps Source Language To Hardware](#how-dwarf-maps-source-language-to-hardware)
-  - [3.2 Examples](#examples)
-    - [3.2.1 Dynamic Array Size](#dynamic-array-size)
-    - [3.2.2 Variable Location in Register](#variable-location-in-register)
-    - [3.2.3 Variable Location in Memory](#variable-location-in-memory)
-    - [3.2.4 Variable Spread Across Different Locations](#variable-spread-across-different-locations)
-    - [3.2.5 Offsetting a Composite Location](#offsetting-a-composite-location)
-  - [3.3 Limitations](#limitations)
-- [4. Extension Solution](#extension-solution)
-  - [4.1 Location Description](#location-description)
-  - [4.2 Stack Location Description Operations](#stack-location-description-operations)
-  - [4.3 Examples](#examples-1)
-    - [4.3.1 Source Language Variable Spilled to Part of a Vector Register](#source-language-variable-spilled-to-part-of-a-vector-register)
-    - [4.3.2 Source Language Variable Spread Across Multiple Vector Registers](#source-language-variable-spread-across-multiple-vector-registers)
-    - [4.3.3 Source Language Variable Spread Across Multiple Kinds of Locations](#source-language-variable-spread-across-multiple-kinds-of-locations)
-    - [4.3.4 Address Spaces](#address-spaces)
-    - [4.3.5 Bit Offsets](#bit-offsets)
-  - [4.4 Call Frame Information (CFI)](#call-frame-information-cfi)
-  - [4.5 Objects Not In Byte Aligned Global Memory](#objects-not-in-byte-aligned-global-memory)
-  - [4.6 Higher Order Operations](#higher-order-operations)
-  - [4.7 Objects In Multiple Places](#objects-in-multiple-places)
-- [5. Conclusion](#conclusion)
-- [A. Changes to DWARF Debugging Information Format Version 5](#a-changes-to-dwarf-debugging-information-format-version-5)
-  - [A.2 General Description](#a-2-general-description)
-    - [A.2.5 DWARF Expressions](#a-2-5-dwarf-expressions)
-      - [A.2.5.1 DWARF Expression Evaluation Context](#a-2-5-1-dwarf-expression-evaluation-context)
-      - [A.2.5.2 DWARF Expression Value](#a-2-5-2-dwarf-expression-value)
-      - [A.2.5.3 DWARF Location Description](#a-2-5-3-dwarf-location-description)
-      - [A.2.5.4 DWARF Operation Expressions](#a-2-5-4-dwarf-operation-expressions)
-        - [A.2.5.4.1 Stack Operations](#a-2-5-4-1-stack-operations)
-        - [A.2.5.4.2 Control Flow Operations](#a-2-5-4-2-control-flow-operations)
-        - [A.2.5.4.3 Value Operations](#a-2-5-4-3-value-operations)
-          - [A.2.5.4.3.1 Literal Operations](#a-2-5-4-3-1-literal-operations)
-          - [A.2.5.4.3.2 Arithmetic and Logical Operations](#a-2-5-4-3-2-arithmetic-and-logical-operations)
-          - [A.2.5.4.3.3 Type Conversion Operations](#a-2-5-4-3-3-type-conversion-operations)
-          - [A.2.5.4.3.4 Special Value Operations](#a-2-5-4-3-4-special-value-operations)
-        - [A.2.5.4.4 Location Description Operations](#a-2-5-4-4-location-description-operations)
-          - [A.2.5.4.4.1 General Location Description Operations](#a-2-5-4-4-1-general-location-description-operations)
-          - [A.2.5.4.4.2 Undefined Location Description Operations](#a-2-5-4-4-2-undefined-location-description-operations)
-          - [A.2.5.4.4.3 Memory Location Description Operations](#a-2-5-4-4-3-memory-location-description-operations)
-          - [A.2.5.4.4.4 Register Location Description Operations](#a-2-5-4-4-4-register-location-description-operations)
-          - [A.2.5.4.4.5 Implicit Location Description Operations](#a-2-5-4-4-5-implicit-location-description-operations)
-          - [A.2.5.4.4.6 Composite Location Description Operations](#a-2-5-4-4-6-composite-location-description-operations)
-      - [A.2.5.5 DWARF Location List Expressions](#a-2-5-5-dwarf-location-list-expressions)
-  - [A.3 Program Scope Entries](#a-3-program-scope-entries)
-    - [A.3.3 Subroutine and Entry Point Entries](#a-3-3-subroutine-and-entry-point-entries)
-      - [A.3.3.5 Low-Level Information](#a-3-3-5-low-level-information)
-    - [A.3.4 Call Site Entries and Parameters](#a-3-4-call-site-entries-and-parameters)
-      - [A.3.4.2 Call Site Parameters](#a-3-4-2-call-site-parameters)
-    - [A.3.5 Lexical Block Entries](#a-3-5-lexical-block-entries)
-  - [A.4 Data Object and Object List Entries](#a-4-data-object-and-object-list-entries)
-    - [A.4.1 Data Object Entries](#a-4-1-data-object-entries)
-  - [A.5 Type Entries](#a-5-type-entries)
-    - [A.5.7 Structure, Union, Class and Interface Type Entries](#a-5-7-structure-union-class-and-interface-type-entries)
-      - [A.5.7.3 Derived or Extended Structures, Classes and Interfaces](#a-5-7-3-derived-or-extended-structures-classes-and-interfaces)
-      - [A.5.7.8 Member Function Entries](#a-5-7-8-member-function-entries)
-    - [A.5.14 Pointer to Member Type Entries](#a-5-14-pointer-to-member-type-entries)
-    - [A.5.16 Dynamic Type Entries](#a-5-16-dynamic-type-entries)
-  - [A.6 Other Debugging Information](#a-6-other-debugging-information)
-    - [A.6.2 Line Number Information](#a-6-2-line-number-information)
-    - [A.6.4 Call Frame Information](#a-6-4-call-frame-information)
-      - [A.6.4.1 Structure of Call Frame Information](#a-6-4-1-structure-of-call-frame-information)
-      - [A.6.4.2 Call Frame Instructions](#a-6-4-2-call-frame-instructions)
-        - [A.6.4.2.1 Row Creation Instructions](#a-6-4-2-1-row-creation-instructions)
-        - [A.6.4.2.2 CFA Definition Instructions](#a-6-4-2-2-cfa-definition-instructions)
-        - [A.6.4.2.3 Register Rule Instructions](#a-6-4-2-3-register-rule-instructions)
-        - [A.6.4.2.4 Row State Instructions](#a-6-4-2-4-row-state-instructions)
-        - [A.6.4.2.5 Padding Instruction](#a-6-4-2-5-padding-instruction)
-      - [A.6.4.3 Call Frame Instruction Usage](#a-6-4-3-call-frame-instruction-usage)
-      - [A.6.4.4 Call Frame Calling Address](#a-6-4-4-call-frame-calling-address)
-  - [A.7 Data Representation](#a-7-data-representation)
-    - [A.7.4 32-Bit and 64-Bit DWARF Formats](#a-7-4-32-bit-and-64-bit-dwarf-formats)
-    - [A.7.5 Format of Debugging Information](#a-7-5-format-of-debugging-information)
-      - [A.7.5.5 Classes and Forms](#a-7-5-5-classes-and-forms)
-    - [A.7.7 DWARF Expressions](#a-7-7-dwarf-expressions)
-      - [A.7.7.1 Operation Expressions](#a-7-7-1-operation-expressions)
-      - [A.7.7.3 Location List Expressions](#a-7-7-3-location-list-expressions)
-- [B. Further Information](#b-further-information)
-
-# 1. Extension
-
-In DWARF 5, expressions are evaluated using a typed value stack, a separate
-location area, and an independent loclist mechanism. This extension unifies all
-three mechanisms into a single generalized DWARF expression evaluation model
-that allows both typed values and location descriptions to be manipulated on the
-evaluation stack. Both single and multiple location descriptions are supported
-on the stack. In addition, the call frame information (CFI) is extended to
-support the full generality of location descriptions. This is done in a manner
-that is backwards compatible with DWARF 5. The extension involves changes to the
-DWARF 5 sections 2.5 (pp 26-38), 2.6 (pp 38-45), and 6.4 (pp 171-182).
-
-The extension permits operations to act on location descriptions in an
-incremental, consistent, and composable manner. It allows a small number of
-operations to be defined to address the requirements of heterogeneous devices as
-well as providing benefits to non-heterogeneous devices. It acts as a foundation
-to provide support for other issues that have been raised that would benefit all
-devices.
-
-Other approaches were explored that involved adding specialized operations and
-rules. However, these resulted in the need for more operations that did not
-compose. It also resulted in operations with context sensitive semantics and
-corner cases that had to be defined. The observation was that numerous
-specialized context sensitive operations are harder for both produces and
-consumers than a smaller number of general composable operations that have
-consistent semantics regardless of context.
-
-First, section [2. Heterogeneous Computing
-Devices](#heterogeneous-computing-devices) describes heterogeneous devices and
-the features they have that are not addressed by DWARF 5. Then section [3. DWARF
-5](#dwarf-5) presents a brief simplified overview of the DWARF 5 expression
-evaluation model that highlights the difficulties for supporting the
-heterogeneous features. Next, section [4. Extension
-Solution](#extension-solution) provides an overview of the proposal, using
-simplified examples to illustrate how it can address the issues of heterogeneous
-devices and also benefit non-heterogeneous devices. Then overall conclusions are
-covered in section [5. Conclusion](#conclusion). Appendix [A. Changes to DWARF
-Debugging Information Format Version
-5](#a-changes-to-dwarf-debugging-information-format-version-5) gives changes
-relative to the DWARF Version 5 standard. Finally, appendix [B. Further
-Information](#b-further-information) has references to further information.
-
-# 2. Heterogeneous Computing Devices
-
-GPUs and other heterogeneous computing devices have features not common to CPU
-computing devices.
-
-These devices often have many more registers than a CPU. This helps reduce
-memory accesses which tend to be more expensive than on a CPU due to the much
-larger number of threads concurrently executing. In addition to traditional
-scalar registers of a CPU, these devices often have many wide vector registers.
-
-![Example GPU Hardware](images/example-gpu-hardware.png)
-
-They may support masked vector instructions that are used by the compiler to map
-high level language threads onto the lanes of the vector registers. As a
-consequence, multiple language threads execute in lockstep as the vector
-instructions are executed. This is termed single instruction multiple thread
-(SIMT) execution.
-
-![SIMT/SIMD Execution Model](images/simt-execution-model.png)
-
-GPUs can have multiple memory address spaces in addition to the single global
-memory address space of a CPU. These additional address spaces are accessed
-using distinct instructions and are often local to a particular thread or group
-of threads.
-
-For example, a GPU may have a per thread block address space that is implemented
-as scratch pad memory with explicit hardware support to isolate portions to
-specific groups of threads created as a single thread block.
-
-A GPU may also use global memory in a non linear manner. For example, to support
-providing a SIMT per lane address space efficiently, there may be instructions
-that support interleaved access.
-
-Through optimization, the source variables may be located across these different
-storage kinds. SIMT execution requires locations to be able to express selection
-of runtime defined pieces of vector registers. With the more complex locations,
-there is a benefit to be able to factorize their calculation which requires all
-location kinds to be supported uniformly, otherwise duplication is necessary.
-
-# 3. DWARF 5
-
-Before presenting the proposed solution to supporting heterogeneous devices, a
-brief overview of the DWARF 5 expression evaluation model will be given to
-highlight the aspects being addressed by the extension.
-
-## 3.1 How DWARF Maps Source Language To Hardware
-
-DWARF is a standardized way to specify debug information. It describes source
-language entities such as compilation units, functions, types, variables, etc.
-It is either embedded directly in sections of the code object executables, or
-split into separate files that they reference.
-
-DWARF maps between source program language entities and their hardware
-representations. For example:
-
-- It maps a hardware instruction program counter to a source language program
-  line, and vice versa.
-- It maps a source language function to the hardware instruction program counter
-  for its entry point.
-- It maps a source language variable to its hardware location when at a
-  particular program counter.
-- It provides information to allow virtual unwinding of hardware registers for a
-  source language function call stack.
-- In addition, it provides numerous other information about the source language
-  program.
-
-In particular, there is great diversity in the way a source language entity
-could be mapped to a hardware location. The location may involve runtime values.
-For example, a source language variable location could be:
-
-- In register.
-- At a memory address.
-- At an offset from the current stack pointer.
-- Optimized away, but with a known compiler time value.
-- Optimized away, but with an unknown value, such as happens for unused
-  variables.
-- Spread across combination of the above kinds of locations.
-- At a memory address, but also transiently loaded into registers.
-
-To support this DWARF 5 defines a rich expression language comprised of loclist
-expressions and operation expressions. Loclist expressions allow the result to
-vary depending on the PC. Operation expressions are made up of a list of
-operations that are evaluated on a simple stack machine.
-
-A DWARF expression can be used as the value of different attributes of different
-debug information entries (DIE). A DWARF expression can also be used as an
-argument to call frame information information (CFI) entry operations. An
-expression is evaluated in a context dictated by where it is used. The context
-may include:
-
-- Whether the expression needs to produce a value or the location of an entity.
-- The current execution point including process, thread, PC, and stack frame.
-- Some expressions are evaluated with the stack initialized with a specific
-  value or with the location of a base object that is available using the
-  DW_OP_push_object_address operation.
-
-## 3.2 Examples
-
-The following examples illustrate how DWARF expressions involving operations are
-evaluated in DWARF 5. DWARF also has expressions involving location lists that
-are not covered in these examples.
-
-### 3.2.1 Dynamic Array Size
-
-The first example is for an operation expression associated with a DIE attribute
-that provides the number of elements in a dynamic array type. Such an attribute
-dictates that the expression must be evaluated in the context of providing a
-value result kind.
-
-![Dynamic Array Size Example](images/01-value.example.png)
-
-In this hypothetical example, the compiler has allocated an array descriptor in
-memory and placed the descriptor's address in architecture register SGPR0. The
-first location of the array descriptor is the runtime size of the array.
-
-A possible expression to retrieve the dynamic size of the array is:
-
-    DW_OP_regval_type SGPR0 Generic
-    DW_OP_deref
-
-The expression is evaluated one operation at a time. Operations have operands
-and can pop and push entries on a stack.
-
-![Dynamic Array Size Example: Step 1](images/01-value.example.frame.1.png)
-
-The expression evaluation starts with the first DW_OP_regval_type operation.
-This operation reads the current value of an architecture register specified by
-its first operand: SGPR0. The second operand specifies the size of the data to
-read. The read value is pushed on the stack. Each stack element is a value and
-its associated type.
-
-![Dynamic Array Size Example: Step 2](images/01-value.example.frame.2.png)
-
-The type must be a DWARF base type. It specifies the encoding, byte ordering,
-and size of values of the type. DWARF defines that each architecture has a
-default generic type: it is an architecture specific integral encoding and byte
-ordering, that is the size of the architecture's global memory address.
-
-The DW_OP_deref operation pops a value off the stack, treats it as a global
-memory address, and reads the contents of that location using the generic type.
-It pushes the read value on the stack as the value and its associated generic
-type.
-
-![Dynamic Array Size Example: Step 3](images/01-value.example.frame.3.png)
-
-The evaluation stops when it reaches the end of the expression. The result of an
-expression that is evaluated with a value result kind context is the top element
-of the stack, which provides the value and its type.
-
-### 3.2.2 Variable Location in Register
-
-This example is for an operation expression associated with a DIE attribute that
-provides the location of a source language variable. Such an attribute dictates
-that the expression must be evaluated in the context of providing a location
-result kind.
-
-DWARF defines the locations of objects in terms of location descriptions.
-
-In this example, the compiler has allocated a source language variable in
-architecture register SGPR0.
-
-![Variable Location in Register Example](images/02-reg.example.png)
-
-A possible expression to specify the location of the variable is:
-
-    DW_OP_regx SGPR0
-
-![Variable Location in Register Example: Step 1](images/02-reg.example.frame.1.png)
-
-The DW_OP_regx operation creates a location description that specifies the
-location of the architecture register specified by the operand: SGPR0. Unlike
-values, location descriptions are not pushed on the stack. Instead they are
-conceptually placed in a location area. Unlike values, location descriptions do
-not have an associated type, they only denote the location of the base of the
-object.
-
-![Variable Location in Register Example: Step 2](images/02-reg.example.frame.2.png)
-
-Again, evaluation stops when it reaches the end of the expression. The result of
-an expression that is evaluated with a location result kind context is the
-location description in the location area.
-
-### 3.2.3 Variable Location in Memory
-
-The next example is for an operation expression associated with a DIE attribute
-that provides the location of a source language variable that is allocated in a
-stack frame. The compiler has placed the stack frame pointer in architecture
-register SGPR0, and allocated the variable at offset 0x10 from the stack frame
-base. The stack frames are allocated in global memory, so SGPR0 contains a
-global memory address.
-
-![Variable Location in Memory Example](images/03-memory.example.png)
-
-A possible expression to specify the location of the variable is:
-
-    DW_OP_regval_type SGPR0 Generic
-    DW_OP_plus_uconst 0x10
-
-![Variable Location in Memory Example: Step 1](images/03-memory.example.frame.1.png)
-
-As in the previous example, the DW_OP_regval_type operation pushes the stack
-frame pointer global memory address onto the stack. The generic type is the size
-of a global memory address.
-
-![Variable Location in Memory Example: Step 2](images/03-memory.example.frame.2.png)
-
-The DW_OP_plus_uconst operation pops a value from the stack, which must have a
-type with an integral encoding, adds the value of its operand, and pushes the
-result back on the stack with the same associated type. In this example, that
-computes the global memory address of the source language variable.
-
-![Variable Location in Memory Example: Step 3](images/03-memory.example.frame.3.png)
-
-Evaluation stops when it reaches the end of the expression. If the expression
-that is evaluated has a location result kind context, and the location area is
-empty, then the top stack element must be a value with the generic type. The
-value is implicitly popped from the stack, and treated as a global memory
-address to create a global memory location description, which is placed in the
-location area. The result of the expression is the location description in the
-location area.
-
-![Variable Location in Memory Example: Step 4](images/03-memory.example.frame.4.png)
-
-### 3.2.4 Variable Spread Across Different Locations
-
-This example is for a source variable that is partly in a register, partly undefined, and partly in memory.
-
-![Variable Spread Across Different Locations Example](images/04-composite.example.png)
-
-DWARF defines composite location descriptions that can have one or more parts.
-Each part specifies a location description and the number of bytes used from it.
-The following operation expression creates a composite location description.
-
-    DW_OP_regx SGPR3
-    DW_OP_piece 4
-    DW_OP_piece 2
-    DW_OP_bregx SGPR0 0x10
-    DW_OP_piece 2
-
-![Variable Spread Across Different Locations Example: Step 1](images/04-composite.example.frame.1.png)
-
-The DW_OP_regx operation creates a register location description in the location
-area.
-
-![Variable Spread Across Different Locations Example: Step 2](images/04-composite.example.frame.2.png)
-
-The first DW_OP_piece operation creates an incomplete composite location
-description in the location area with a single part. The location description in
-the location area is used to define the beginning of the part for the size
-specified by the operand, namely 4 bytes.
-
-![Variable Spread Across Different Locations Example: Step 3](images/04-composite.example.frame.3.png)
-
-A subsequent DW_OP_piece adds a new part to an incomplete composite location
-description already in the location area. The parts form a contiguous set of
-bytes. If there are no other location descriptions in the location area, and no
-value on the stack, then the part implicitly uses the undefined location
-description. Again, the operand specifies the size of the part in bytes. The
-undefined location description can be used to indicate a part that has been
-optimized away. In this case, 2 bytes of undefined value.
-
-![Variable Spread Across Different Locations Example: Step 4](images/04-composite.example.frame.4.png)
-
-The DW_OP_bregx operation reads the architecture register specified by the first
-operand (SGPR0) as the generic type, adds the value of the second operand
-(0x10), and pushes the value on the stack.
-
-![Variable Spread Across Different Locations Example: Step 5](images/04-composite.example.frame.5.png)
-
-The next DW_OP_piece operation adds another part to the already created
-incomplete composite location.
-
-If there is no other location in the location area, but there is a value on
-stack, the new part is a memory location description. The memory address used is
-popped from the stack. In this case, the operand of 2 indicates there are 2
-bytes from memory.
-
-![Variable Spread Across Different Locations Example: Step 6](images/04-composite.example.frame.6.png)
-
-Evaluation stops when it reaches the end of the expression. If the expression
-that is evaluated has a location result kind context, and the location area has
-an incomplete composite location description, the incomplete composite location
-is implicitly converted to a complete composite location description. The result
-of the expression is the location description in the location area.
-
-![Variable Spread Across Different Locations Example: Step 7](images/04-composite.example.frame.7.png)
-
-### 3.2.5 Offsetting a Composite Location
-
-This example attempts to extend the previous example to offset the composite
-location description it created. The [3.2.3 Variable Location in
-Memory](#variable-location-in-memory) example conveniently used the DW_OP_plus
-operation to offset a memory address.
-
-    DW_OP_regx SGPR3
-    DW_OP_piece 4
-    DW_OP_piece 2
-    DW_OP_bregx SGPR0 0x10
-    DW_OP_piece 2
-    DW_OP_plus_uconst 5
-
-![Offsetting a Composite Location Example: Step 6](images/05-composite-plus.example.frame.1.png)
-
-However, DW_OP_plus cannot be used to offset a composite location. It only
-operates on the stack.
-
-![Offsetting a Composite Location Example: Step 7](images/05-composite-plus.example.frame.2.png)
-
-To offset a composite location description, the compiler would need to make a
-different composite location description, starting at the part corresponding to
-the offset. For example:
-
-    DW_OP_piece 1
-    DW_OP_bregx SGPR0 0x10
-    DW_OP_piece 2
-
-This illustrates that operations on stack values are not composable with
-operations on location descriptions.
-
-## 3.3 Limitations
-
-DWARF 5 is unable to describe variables in runtime indexed parts of registers.
-This is required to describe a source variable that is located in a lane of a
-SIMT vector register.
-
-Some features only work when located in global memory. The type attribute
-expressions require a base object which could be in any kind of location.
-
-DWARF procedures can only accept global memory address arguments. This limits
-the ability to factorize the creation of locations that involve other location
-kinds.
-
-There are no vector base types. This is required to describe vector registers.
-
-There is no operation to create a memory location in a non-global address space.
-Only the dereference operation supports providing an address space.
-
-CFI location expressions do not allow composite locations or non-global address
-space memory locations. Both these are needed in optimized code for devices with
-vector registers and address spaces.
-
-Bit field offsets are only supported in a limited way for register locations.
-Supporting them in a uniform manner for all location kinds is required to
-support languages with bit sized entities.
-
-# 4. Extension Solution
-
-This section outlines the extension to generalize the DWARF expression evaluation
-model to allow location descriptions to be manipulated on the stack. It presents
-a number of simplified examples to demonstrate the benefits and how the extension
-solves the issues of heterogeneous devices. It presents how this is done in
-a manner that is backwards compatible with DWARF 5.
-
-## 4.1 Location Description
-
-In order to have consistent, composable operations that act on location
-descriptions, the extension defines a uniform way to handle all location kinds.
-That includes memory, register, implicit, implicit pointer, undefined, and
-composite location descriptions.
-
-Each kind of location description is conceptually a zero-based offset within a
-piece of storage. The storage is a contiguous linear organization of a certain
-number of bytes (see below for how this is extended to support bit sized
-storage).
-
-- For global memory, the storage is the linear stream of bytes of the
-  architecture's address size.
-- For each separate architecture register, it is the linear stream of bytes of
-  the size of that specific register.
-- For an implicit, it is the linear stream of bytes of the value when
-  represented using the value's base type which specifies the encoding, size,
-  and byte ordering.
-- For undefined, it is an infinitely sized linear stream where every byte is
-  undefined.
-- For composite, it is a linear stream of bytes defined by the composite's parts.
-
-## 4.2 Stack Location Description Operations
-
-The DWARF expression stack is extended to allow each stack entry to either be a
-value or a location description.
-
-Evaluation rules are defined to implicitly convert a stack element that is a
-value to a location description, or vice versa, so that all DWARF 5 expressions
-continue to have the same semantics. This reflects that a memory address is
-effectively used as a proxy for a memory location description.
-
-For each place that allows a DWARF expression to be specified, it is defined if
-the expression is to be evaluated as a value or a location description.
-
-Existing DWARF expression operations that are used to act on memory addresses
-are generalized to act on any location description kind. For example, the
-DW_OP_deref operation pops a location description rather than a memory address
-value from the stack and reads the storage associated with the location kind
-starting at the location description's offset.
-
-Existing DWARF expression operations that create location descriptions are
-changed to pop and push location descriptions on the stack. For example, the
-DW_OP_value, DW_OP_regx, DW_OP_implicit_value, DW_OP_implicit_pointer,
-DW_OP_stack_value, and DW_OP_piece.
-
-New operations that act on location descriptions can be added. For example, a
-DW_OP_offset operation that modifies the offset of the location description on
-top of the stack. Unlike the DW_OP_plus operation that only works with memory
-address, a DW_OP_offset operation can work with any location kind.
-
-To allow incremental and nested creation of composite location descriptions, a
-DW_OP_piece_end can be defined to explicitly indicate the last part of a
-composite. Currently, creating a composite must always be the last operation of
-an expression.
-
-A DW_OP_undefined operation can be defined that explicitly creates the undefined
-location description. Currently this is only possible as a piece of a composite
-when the stack is empty.
-
-## 4.3 Examples
-
-This section provides some motivating examples to illustrate the benefits that
-result from allowing location descriptions on the stack.
-
-### 4.3.1 Source Language Variable Spilled to Part of a Vector Register
-
-A compiler generating code for a GPU may allocate a source language variable
-that it proves has the same value for every lane of a SIMT thread in a scalar
-register. It may then need to spill that scalar register. To avoid the high cost
-of spilling to memory, it may spill to a fixed lane of one of the numerous
-vector registers.
-
-![Source Language Variable Spilled to Part of a Vector Register Example](images/06-extension-spill-sgpr-to-static-vpgr-lane.example.png)
-
-The following expression defines the location of a source language variable that
-the compiler allocated in a scalar register, but had to spill to lane 5 of a
-vector register at this point of the code.
-
-    DW_OP_regx VGPR0
-    DW_OP_offset_uconst 20
-
-![Source Language Variable Spilled to Part of a Vector Register Example: Step 1](images/06-extension-spill-sgpr-to-static-vpgr-lane.example.frame.1.png)
-
-The DW_OP_regx pushes a register location description on the stack. The storage
-for the register is the size of the vector register. The register location
-description conceptually references that storage with an initial offset of 0.
-The architecture defines the byte ordering of the register.
-
-![Source Language Variable Spilled to Part of a Vector Register Example: Step 2](images/06-extension-spill-sgpr-to-static-vpgr-lane.example.frame.2.png)
-
-The DW_OP_offset_uconst pops a location description off the stack, adds its
-operand value to the offset, and pushes the updated location description back on
-the stack. In this case the source language variable is being spilled to lane 5
-and each lane's component which is 32-bits (4 bytes), so the offset is 5*4=20.
-
-![Source Language Variable Spilled to Part of a Vector Register Example: Step 3](images/06-extension-spill-sgpr-to-static-vpgr-lane.example.frame.3.png)
-
-The result of the expression evaluation is the location description on the top
-of the stack.
-
-An alternative approach could be for the target to define distinct register
-names for each part of each vector register. However, this is not practical for
-GPUs due to the sheer number of registers that would have to be defined. It
-would also not permit a runtime index into part of the whole register to be used
-as shown in the next example.
-
-### 4.3.2 Source Language Variable Spread Across Multiple Vector Registers
-
-A compiler may generate SIMT code for a GPU. Each source language thread of
-execution is mapped to a single lane of the GPU thread. Source language
-variables that are mapped to a register, are mapped to the lane component of the
-vector registers corresponding to the source language's thread of execution.
-
-The location expression for such variables must therefore be executed in the
-context of the focused source language thread of execution. A DW_OP_push_lane
-operation can be defined to push the value of the lane for the currently focused
-source language thread of execution. The value to use would be provided by the
-consumer of DWARF when it evaluates the location expression.
-
-If the source language variable is larger than the size of the vector register
-lane component, then multiple vector registers are used. Each source language
-thread of execution will only use the vector register components for its
-associated lane.
-
-![Source Language Variable Spread Across Multiple Vector Registers Example](images/07-extension-multi-lane-vgpr.example.png)
-
-The following expression defines the location of a source language variable that
-has to occupy two vector registers. A composite location description is created
-that combines the two parts. It will give the correct result regardless of which
-lane corresponds to the source language thread of execution that the user is
-focused on.
-
-    DW_OP_regx VGPR0
-    DW_OP_push_lane
-    DW_OP_uconst 4
-    DW_OP_mul
-    DW_OP_offset
-    DW_OP_piece 4
-    DW_OP_regx VGPR1
-    DW_OP_push_lane
-    DW_OP_uconst 4
-    DW_OP_mul
-    DW_OP_offset
-    DW_OP_piece 4
-
-![Source Language Variable Spread Across Multiple Vector Registers Example: Step 1](images/07-extension-multi-lane-vgpr.example.frame.1.png)
-
-The DW_OP_regx VGPR0 pushes a location description for the first register.
-
-![Source Language Variable Spread Across Multiple Vector Registers Example: Step 2](images/07-extension-multi-lane-vgpr.example.frame.2.png)
-
-The DW_OP_push_lane; DW_OP_uconst 4; DW_OP_mul calculates the offset for the
-focused lanes vector register component as 4 times the lane number.
-
-![Source Language Variable Spread Across Multiple Vector Registers Example: Step 3](images/07-extension-multi-lane-vgpr.example.frame.3.png)
-
-![Source Language Variable Spread Across Multiple Vector Registers Example: Step 4](images/07-extension-multi-lane-vgpr.example.frame.4.png)
-
-![Source Language Variable Spread Across Multiple Vector Registers Example: Step 5](images/07-extension-multi-lane-vgpr.example.frame.5.png)
-
-The DW_OP_offset adjusts the register location description's offset to the
-runtime computed value.
-
-![Source Language Variable Spread Across Multiple Vector Registers Example: Step 6](images/07-extension-multi-lane-vgpr.example.frame.6.png)
-
-The DW_OP_piece either creates a new composite location description, or adds a
-new part to an existing incomplete one. It pops the location description to use
-for the new part. It then pops the next stack element if it is an incomplete
-composite location description, otherwise it creates a new incomplete composite
-location description with no parts. Finally it pushes the incomplete composite
-after adding the new part.
-
-In this case a register location description is added to a new incomplete
-composite location description. The 4 of the DW_OP_piece specifies the size of
-the register storage that comprises the part. Note that the 4 bytes start at the
-computed register offset.
-
-For backwards compatibility, if the stack is empty or the top stack element is
-an incomplete composite, an undefined location description is used for the part.
-If the top stack element is a generic base type value, then it is implicitly
-converted to a global memory location description with an offset equal to the
-value.
-
-![Source Language Variable Spread Across Multiple Vector Registers Example: Step 7](images/07-extension-multi-lane-vgpr.example.frame.7.png)
-
-The rest of the expression does the same for VGPR1. However, when the
-DW_OP_piece is evaluated there is an incomplete composite on the stack. So the
-VGPR1 register location description is added as a second part.
-
-![Source Language Variable Spread Across Multiple Vector Registers Example: Step 8](images/07-extension-multi-lane-vgpr.example.frame.8.png)
-
-![Source Language Variable Spread Across Multiple Vector Registers Example: Step 9](images/07-extension-multi-lane-vgpr.example.frame.9.png)
-
-![Source Language Variable Spread Across Multiple Vector Registers Example: Step 10](images/07-extension-multi-lane-vgpr.example.frame.10.png)
-
-![Source Language Variable Spread Across Multiple Vector Registers Example: Step 11](images/07-extension-multi-lane-vgpr.example.frame.11.png)
-
-![Source Language Variable Spread Across Multiple Vector Registers Example: Step 12](images/07-extension-multi-lane-vgpr.example.frame.12.png)
-
-![Source Language Variable Spread Across Multiple Vector Registers Example: Step 13](images/07-extension-multi-lane-vgpr.example.frame.13.png)
-
-At the end of the expression, if the top stack element is an incomplete
-composite location description, it is converted to a complete location
-description and returned as the result.
-
-![Source Language Variable Spread Across Multiple Vector Registers Example: Step 14](images/07-extension-multi-lane-vgpr.example.frame.14.png)
-
-### 4.3.3 Source Language Variable Spread Across Multiple Kinds of Locations
-
-This example is the same as the previous one, except the first 2 bytes of the
-second vector register have been spilled to memory, and the last 2 bytes have
-been proven to be a constant and optimized away.
-
-![Source Language Variable Spread Across Multiple Kinds of Locations Example](images/08-extension-mixed-composite.example.png)
-
-    DW_OP_regx VGPR0
-    DW_OP_push_lane
-    DW_OP_uconst 4
-    DW_OP_mul
-    DW_OP_offset
-    DW_OP_piece 4
-    DW_OP_addr 0xbeef
-    DW_OP_piece 2
-    DW_OP_uconst 0xf00d
-    DW_OP_stack_value
-    DW_OP_piece 2
-    DW_OP_piece_end
-
-The first 6 operations are the same.
-
-![Source Language Variable Spread Across Multiple Kinds of Locations Example: Step 7](images/08-extension-mixed-composite.example.frame.1.png)
-
-The DW_OP_addr operation pushes a global memory location description on the
-stack with an offset equal to the address.
-
-![Source Language Variable Spread Across Multiple Kinds of Locations Example: Step 8](images/08-extension-mixed-composite.example.frame.2.png)
-
-The next DW_OP_piece adds the global memory location description as the next 2
-byte part of the composite.
-
-![Source Language Variable Spread Across Multiple Kinds of Locations Example: Step 9](images/08-extension-mixed-composite.example.frame.3.png)
-
-The DW_OP_uconst 0xf00d; DW_OP_stack_value pushes an implicit location
-description on the stack. The storage of the implicit location description is
-the representation of the value 0xf00d using the generic base type's encoding,
-size, and byte ordering.
-
-![Source Language Variable Spread Across Multiple Kinds of Locations Example: Step 10](images/08-extension-mixed-composite.example.frame.4.png)
-
-![Source Language Variable Spread Across Multiple Kinds of Locations Example: Step 11](images/08-extension-mixed-composite.example.frame.5.png)
-
-The final DW_OP_piece adds 2 bytes of the implicit location description as the
-third part of the composite location description.
-
-![Source Language Variable Spread Across Multiple Kinds of Locations Example: Step 12](images/08-extension-mixed-composite.example.frame.6.png)
-
-The DW_OP_piece_end operation explicitly makes the incomplete composite location
-description into a complete location description. This allows a complete
-composite location description to be created on the stack that can be used as
-the location description of another following operation. For example, the
-DW_OP_offset can be applied to it. More practically, it permits creation of
-multiple composite location descriptions on the stack which can be used to pass
-arguments to a DWARF procedure using a DW_OP_call* operation. This can be
-beneficial to factor the incrementally creation of location descriptions.
-
-![Source Language Variable Spread Across Multiple Kinds of Locations Example: Step 12](images/08-extension-mixed-composite.example.frame.7.png)
-
-### 4.3.4 Address Spaces
-
-Heterogeneous devices can have multiple hardware supported address spaces which
-use specific hardware instructions to access them.
-
-For example, GPUs that use SIMT execution may provide hardware support to access
-memory such that each lane can see a linear memory view, while the backing
-memory is actually being accessed in an interleaved manner so that the locations
-for each lanes Nth dword are contiguous. This minimizes cache lines read by the
-SIMT execution.
-
-![Address Spaces Example](images/09-extension-form-aspace.example.png)
-
-The following expression defines the location of a source language variable that
-is allocated at offset 0x10 in the current subprograms stack frame. The
-subprogram stack frames are per lane and reside in an interleaved address space.
-
-    DW_OP_regval_type SGPR0 Generic
-    DW_OP_uconst 1
-    DW_OP_form_aspace_address
-    DW_OP_offset 0x10
-
-![Address Spaces Example: Step 1](images/09-extension-form-aspace.example.frame.1.png)
-
-The DW_OP_regval_type operation pushes the contents of SGPR0 as a generic value.
-This is the register that holds the address of the current stack frame.
-
-![Address Spaces Example: Step 2](images/09-extension-form-aspace.example.frame.2.png)
-
-The DW_OP_uconst operation pushes the address space number. Each architecture
-defines the numbers it uses in DWARF. In this case, address space 1 is being
-used as the per lane memory.
-
-![Address Spaces Example: Step 3](images/09-extension-form-aspace.example.frame.3.png)
-
-The DW_OP_form_aspace_address operation pops a value and an address space
-number. Each address space is associated with a separate storage. A memory
-location description is pushed which refers to the address space's storage, with
-an offset of the popped value.
-
-![Address Spaces Example: Step 4](images/09-extension-form-aspace.example.frame.4.png)
-
-All operations that act on location descriptions work with memory locations
-regardless of their address space.
-
-Every architecture defines address space 0 as the default global memory address
-space.
-
-Generalizing memory location descriptions to include an address space component
-avoids having to create specialized operations to work with address spaces.
-
-The source variable is at offset 0x10 in the stack frame. The DW_OP_offset
-operation works on memory location descriptions that have an address space just
-like for any other kind of location description.
-
-![Address Spaces Example: Step 5](images/09-extension-form-aspace.example.frame.5.png)
-
-The only operations in DWARF 5 that take an address space are DW_OP_xderef*.
-They treat a value as the address in a specified address space, and read its
-contents. There is no operation to actually create a location description that
-references an address space. There is no way to include address space memory
-locations in parts of composite locations.
-
-Since DW_OP_piece now takes any kind of location description for its pieces, it
-is now possible for parts of a composite to involve locations in different
-address spaces. For example, this can happen when parts of a source variable
-allocated in a register are spilled to a stack frame that resides in the
-non-global address space.
-
-### 4.3.5 Bit Offsets
-
-With the generalization of location descriptions on the stack, it is possible to
-define a DW_OP_bit_offset operation that adjusts the offset of any kind of
-location in terms of bits rather than bytes. The offset can be a runtime
-computed value. This is generally useful for any source language that support
-bit sized entities, and for registers that are not a whole number of bytes.
-
-DWARF 5 only supports bit fields in composites using DW_OP_bit_piece. It does
-not support runtime computed offsets which can happen for bit field packed
-arrays. It is also not generally composable as it must be the last part of an
-expression.
-
-The following example defines a location description for a source variable that
-is allocated starting at bit 20 of a register. A similar expression could be
-used if the source variable was at a bit offset within memory or a particular
-address space, or if the offset is a runtime value.
-
-![Bit Offsets Example](images/10-extension-bit-offset.example.png)
-
-    DW_OP_regx SGPR3
-    DW_OP_uconst 20
-    DW_OP_bit_offset
-
-![Bit Offsets Example: Step 1](images/10-extension-bit-offset.example.frame.1.png)
-
-![Bit Offsets Example: Step 2](images/10-extension-bit-offset.example.frame.2.png)
-
-![Bit Offsets Example: Step 3](images/10-extension-bit-offset.example.frame.3.png)
-
-The DW_OP_bit_offset operation pops a value and location description from the
-stack. It pushes the location description after updating its offset using the
-value as a bit count.
-
-![Bit Offsets Example: Step 4](images/10-extension-bit-offset.example.frame.4.png)
-
-The ordering of bits within a byte, like byte ordering, is defined by the target
-architecture. A base type could be extended to specify bit ordering in addition
-to byte ordering.
-
-## 4.4 Call Frame Information (CFI)
-
-DWARF defines call frame information (CFI) that can be used to virtually unwind
-the subprogram call stack. This involves determining the location where register
-values have been spilled. DWARF 5 limits these locations to either be registers
-or global memory. As shown in the earlier examples, heterogeneous devices may
-spill registers to parts of other registers, to non-global memory address
-spaces, or even a composite of different location kinds.
-
-Therefore, the extension extends the CFI rules to support any kind of location
-description, and operations to create locations in address spaces.
-
-## 4.5 Objects Not In Byte Aligned Global Memory
-
-DWARF 5 only effectively supports byte aligned memory locations on the stack by
-using a global memory address as a proxy for a memory location description. This
-is a problem for attributes that define DWARF expressions that require the
-location of some source language entity that is not allocated in byte aligned
-global memory.
-
-For example, the DWARF expression of the DW_AT_data_member_location attribute is
-evaluated with an initial stack containing the location of a type instance
-object. That object could be located in a register, in a non-global memory
-address space, be described by a composite location description, or could even
-be an implicit location description.
-
-A similar problem exists for DWARF expressions that use the
-DW_OP_push_object_address operation. This operation pushes the location of a
-program object associated with the attribute that defines the expression.
-
-Allowing any kind of location description on the stack permits the DW_OP_call*
-operations to be used to factor the creation of location descriptions. The
-inputs and outputs of the call are passed on the stack. For example, on GPUs an
-expression can be defined to describe the effective PC of inactive lanes of SIMT
-execution. This is naturally done by composing the result of expressions for
-each nested control flow region. This can be done by making each control flow
-region have its own DWARF procedure, and then calling it from the expressions of
-the nested control flow regions. The alternative is to make each control flow
-region have the complete expression which results in much larger DWARF and is
-less convenient to generate.
-
-GPU compilers work hard to allocate objects in the larger number of registers to
-reduce memory accesses, they have to use different memory address spaces, and
-they perform optimizations that result in composites of these. Allowing
-operations to work with any kind of location description enables creating
-expressions that support all of these.
-
-Full general support for bit fields and implicit locations benefits
-optimizations on any target.
-
-## 4.6 Higher Order Operations
-
-The generalization allows an elegant way to add higher order operations that
-create location descriptions out of other location descriptions in a general
-composable manner.
-
-For example, a DW_OP_extend operation could create a composite location
-description out of a location description, an element size, and an element
-count. The resulting composite would effectively be a vector of element count
-elements with each element being the same location description of the specified
-bit size.
-
-A DW_OP_select_bit_piece operation could create a composite location description
-out of two location descriptions, a bit mask value, and an element size. The
-resulting composite would effectively be a vector of elements, selecting from
-one of the two input locations according to the bit mask.
-
-These could be used in the expression of an attribute that computes the
-effective PC of lanes of SIMT execution. The vector result efficiently computes
-the PC for each SIMT lane at once. The mask could be the hardware execution mask
-register that controls which SIMT lanes are executing. For active divergent
-lanes the vector element would be the current PC, and for inactive divergent
-lanes the PC would correspond to the source language line at which the lane is
-logically positioned.
-
-Similarly, a DW_OP_overlay_piece operation could be defined that creates a
-composite location description out of two location descriptions, an offset
-value, and a size. The resulting composite would consist of parts that are
-equivalent to one of the location descriptions, but with the other location
-description replacing a slice defined by the offset and size. This could be used
-to efficiently express a source language array that has had a set of elements
-promoted into a vector register when executing a set of iterations of a loop in
-a SIMD manner.
-
-## 4.7 Objects In Multiple Places
-
-A compiler may allocate a source variable in stack frame memory, but for some
-range of code may promote it to a register. If the generated code does not
-change the register value, then there is no need to save it back to memory.
-Effectively, during that range, the source variable is in both memory and a
-register. If a consumer, such as a debugger, allows the user to change the value
-of the source variable in that PC range, then it would need to change both
-places.
-
-DWARF 5 supports loclists which are able to specify the location of a source
-language entity is in different places at different PC locations. It can also
-express that a source language entity is in multiple places at the same time.
-
-DWARF 5 defines operation expressions and loclists separately. In general, this
-is adequate as non-memory location descriptions can only be computed as the last
-step of an expression evaluation.
-
-However, allowing location descriptions on the stack permits non-memory location
-descriptions to be used in the middle of expression evaluation. For example, the
-DW_OP_call* and DW_OP_implicit_pointer operations can result in evaluating the
-expression of a DW_AT_location attribute of a DIE. The DW_AT_location attribute
-allows the loclist form. So the result could include multiple location
-descriptions.
-
-Similarly, the DWARF expression associated with attributes such as
-DW_AT_data_member_location that are evaluated with an initial stack containing a
-location description, or a DWARF operation expression that uses the
-DW_OP_push_object_address operation, may want to act on the result of another
-expression that returned a location description involving multiple places.
-
-Therefore, the extension needs to define how expression operations that use those
-results will behave. The extension does this by generalizing the expression stack
-to allow an entry to be one or more single location descriptions. In doing this,
-it unifies the definitions of DWARF operation expressions and loclist
-expressions in a natural way.
-
-All operations that act on location descriptions are extended to act on multiple
-single location descriptions. For example, the DW_OP_offset operation adds the
-offset to each single location description. The DW_OP_deref* operations simply
-read the storage of one of the single location descriptions, since multiple
-single location descriptions must all hold the same value. Similarly, if the
-evaluation of a DWARF expression results in multiple single location
-descriptions, the consumer can ensure any updates are done to all of them, and
-any reads can use any one of them.
-
-# 5. Conclusion
-
-A strength of DWARF is that it has generally sought to provide generalized
-composable solutions that address many problems, rather than solutions that only
-address one-off issues. This extension attempts to follow that tradition by
-defining a backwards compatible composable generalization that can address a
-significant family of issues. It addresses the specific issues present for
-heterogeneous computing devices, provides benefits for non-heterogeneous
-devices, and can help address a number of other previously reported issues.
-
-# A. Changes to DWARF Debugging Information Format Version 5
-
-> NOTE: This appendix provides changes relative to DWARF Version 5. It has been
-> defined such that it is backwards compatible with DWARF Version 5.
-> Non-normative text is shown in <i>italics</i>. The section numbers generally
-> correspond to those in the DWARF Version 5 standard unless specified
-> otherwise. Definitions are given to clarify how existing expression
-> operations, CFI operations, and attributes behave with respect to generalized
-> location descriptions that support multiple places.
->
-> > NOTE: Notes are included to describe how the changes are to be applied to
-> > the DWARF Version 5 standard. They also describe rational and issues that
-> > may need further consideration.
-
-## A.2 General Description
-
-### A.2.5 DWARF Expressions
-
-> NOTE: This section, and its nested sections, replaces DWARF Version 5 section
-> 2.5 and section 2.6. It is based on the text of the existing DWARF Version 5
-> standard.
-
-DWARF expressions describe how to compute a value or specify a location.
-
-<i>The evaluation of a DWARF expression can provide the location of an object,
-the value of an array bound, the length of a dynamic string, the desired value
-itself, and so on.</i>
-
-If the evaluation of a DWARF expression does not encounter an error, then it can
-either result in a value (see [2.5.2 DWARF Expression
-Value](#dwarf-expression-value)) or a location description (see [2.5.3 DWARF
-Location Description](#dwarf-location-description)). When a DWARF expression
-is evaluated, it may be specified whether a value or location description is
-required as the result kind.
-
-If a result kind is specified, and the result of the evaluation does not match
-the specified result kind, then the implicit conversions described in [2.5.4.4.3
-Memory Location Description
-Operations](#memory-location-description-operations) are performed if
-valid. Otherwise, the DWARF expression is ill-formed.
-
-If the evaluation of a DWARF expression encounters an evaluation error, then the
-result is an evaluation error.
-
-> NOTE: Decided to define the concept of an evaluation error. An alternative is
-> to introduce an undefined value base type in a similar way to location
-> descriptions having an undefined location description. Then operations that
-> encounter an evaluation error can return the undefined location description or
-> value with an undefined base type.
->
-> All operations that act on values would return an undefined entity if given an
-> undefined value. The expression would then always evaluate to completion, and
-> can be tested to determine if it is an undefined entity.
->
-> However, this would add considerable additional complexity and does not match
-> that GDB throws an exception when these evaluation errors occur.
-
-If a DWARF expression is ill-formed, then the result is undefined.
-
-The following sections detail the rules for when a DWARF expression is
-ill-formed or results in an evaluation error.
-
-A DWARF expression can either be encoded as an operation expression (see [2.5.4
-DWARF Operation Expressions](#dwarf-operation-expressions)), or as a
-location list expression (see [2.5.5 DWARF Location List
-Expressions](#dwarf-location-list-expressions)).
-
-#### A.2.5.1 DWARF Expression Evaluation Context
-
-A DWARF expression is evaluated in a context that can include a number of
-context elements. If multiple context elements are specified then they must be
-self consistent or the result of the evaluation is undefined. The context
-elements that can be specified are:
-
-1.  <i>A current result kind</i>
-
-    The kind of result required by the DWARF expression evaluation. If specified
-    it can be a location description or a value.
-
-2.  <i>A current thread</i>
-
-    The target architecture thread identifier of the source program thread of
-    execution for which a user presented expression is currently being
-    evaluated.
-
-    It is required for operations that are related to target architecture
-    threads.
-
-    <i>For example, the `DW_OP_regval_type` operation.</i>
-
-3.  <i>A current call frame</i>
-
-    The target architecture call frame identifier. It identifies a call frame
-    that corresponds to an active invocation of a subprogram in the current
-    thread. It is identified by its address on the call stack. The address is
-    referred to as the Canonical Frame Address (CFA). The call frame information
-    is used to determine the CFA for the call frames of the current thread's
-    call stack (see [6.4 Call Frame Information](#call-frame-information)).
-
-    It is required for operations that specify target architecture registers to
-    support virtual unwinding of the call stack.
-
-    <i>For example, the `DW_OP_*reg*` operations.</i>
-
-    If specified, it must be an active call frame in the current thread.
-    Otherwise the result is undefined.
-
-    If it is the currently executing call frame, then it is termed the top call
-    frame.
-
-4.  <i>A current program location</i>
-
-    The target architecture program location corresponding to the current call
-    frame of the current thread.
-
-    The program location of the top call frame is the target architecture
-    program counter for the current thread. The call frame information is used
-    to obtain the value of the return address register to determine the program
-    location of the other call frames (see [6.4 Call Frame
-    Information](#call-frame-information)).
-
-    It is required for the evaluation of location list expressions to select
-    amongst multiple program location ranges. It is required for operations that
-    specify target architecture registers to support virtual unwinding of the
-    call stack (see [6.4 Call Frame Information](#call-frame-information)).
-
-    If specified:
-
-    - If the current call frame is the top call frame, it must be the current
-      target architecture program location.
-    - If the current call frame F is not the top call frame, it must be the
-      program location associated with the call site in the current caller frame
-      F that invoked the callee frame.
-    - Otherwise the result is undefined.
-
-5.  <i>A current compilation unit</i>
-
-    The compilation unit debug information entry that contains the DWARF
-    expression being evaluated.
-
-    It is required for operations that reference debug information associated
-    with the same compilation unit, including indicating if such references use
-    the 32-bit or 64-bit DWARF format. It can also provide the default address
-    space address size if no current target architecture is specified.
-
-    <i>For example, the `DW_OP_constx` and `DW_OP_addrx` operations.</i>
-
-    <i>Note that this compilation unit may not be the same as the compilation
-    unit determined from the loaded code object corresponding to the current
-    program location. For example, the evaluation of the expression E associated
-    with a `DW_AT_location` attribute of the debug information entry operand of
-    the `DW_OP_call*` operations is evaluated with the compilation unit that
-    contains E and not the one that contains the `DW_OP_call*` operation
-    expression.</i>
-
-6.  <i>A current target architecture</i>
-
-    The target architecture.
-
-    It is required for operations that specify target architecture specific
-    entities.
-
-    <i>For example, target architecture specific entities include DWARF register
-    identifiers, DWARF address space identifiers, the default address space, and
-    the address space address sizes.</i>
-
-    If specified:
-
-    - If the current thread is specified, then the current target architecture
-      must be the same as the target architecture of the current thread.
-    - If the current compilation unit is specified, then the current target
-      architecture default address space address size must be the same as the
-      `address_size` field in the header of the current compilation unit and any
-      associated entry in the `.debug_aranges` section.
-    - If the current program location is specified, then the current target
-      architecture must be the same as the target architecture of any line
-      number information entry (see [6.2 Line Number
-      Information](#line-number-information)) corresponding to the current
-      program location.
-    - If the current program location is specified, then the current target
-      architecture default address space address size must be the same as the
-      `address_size` field in the header of any entry corresponding to the
-      current program location in the `.debug_addr`, `.debug_line`,
-      `.debug_rnglists`, `.debug_rnglists.dwo`, `.debug_loclists`, and
-      `.debug_loclists.dwo` sections.
-    - Otherwise the result is undefined.
-
-7.  <i>A current object</i>
-
-    The location description of a program object.
-
-    It is required for the `DW_OP_push_object_address` operation.
-
-    <i>For example, the `DW_AT_data_location` attribute on type debug
-    information entries specifies the program object corresponding to a runtime
-    descriptor as the current object when it evaluates its associated
-    expression.</i>
-
-    The result is undefined if the location descriptor is invalid (see [3.5.3
-    DWARF Location Description](#dwarf-location-description)).
-
-8.  <i>An initial stack</i>
-
-    This is a list of values or location descriptions that will be pushed on the
-    operation expression evaluation stack in the order provided before
-    evaluation of an operation expression starts.
-
-    Some debugger information entries have attributes that evaluate their DWARF
-    expression value with initial stack entries. In all other cases the initial
-    stack is empty.
-
-    The result is undefined if any location descriptors are invalid (see [3.5.3
-    DWARF Location Description](#dwarf-location-description)).
-
-If the evaluation requires a context element that is not specified, then the
-result of the evaluation is an error.
-
-<i>A DWARF expression for a location description may be able to be evaluated
-without a thread, call frame, program location, or architecture context. For
-example, the location of a global variable may be able to be evaluated without
-such context. If the expression evaluates with an error then it may indicate the
-variable has been optimized and so requires more context.</i>
-
-<i>The DWARF expression for call frame information (see [6.4 Call Frame
-Information](#call-frame-information)) operations are restricted to those
-that do not require the compilation unit context to be specified.</i>
-
-The DWARF is ill-formed if all the `address_size` fields in the headers of all
-the entries in the `.debug_info`, `.debug_addr`, `.debug_line`,
-`.debug_rnglists`, `.debug_rnglists.dwo`, `.debug_loclists`, and
-`.debug_loclists.dwo` sections corresponding to any given program location do
-not match.
-
-#### A.2.5.2 DWARF Expression Value
-
-A value has a type and a literal value. It can represent a literal value of any
-supported base type of the target architecture. The base type specifies the
-size, encoding, and endianity of the literal value.
-
-> NOTE: It may be desirable to add an implicit pointer base type encoding. It
-> would be used for the type of the value that is produced when the
-> `DW_OP_deref*` operation retrieves the full contents of an implicit pointer
-> location storage created by the `DW_OP_implicit_pointer` operation. The
-> literal value would record the debugging information entry and byte
-> displacement specified by the associated `DW_OP_implicit_pointer` operation.
-
-There is a distinguished base type termed the generic type, which is an integral
-type that has the size of an address in the target architecture default address
-space, a target architecture defined endianity, and unspecified signedness.
-
-<i>The generic type is the same as the unspecified type used for stack
-operations defined in DWARF Version 4 and before.</i>
-
-An integral type is a base type that has an encoding of `DW_ATE_signed`,
-`DW_ATE_signed_char`, `DW_ATE_unsigned`, `DW_ATE_unsigned_char`,
-`DW_ATE_boolean`, or any target architecture defined integral encoding in the
-inclusive range `DW_ATE_lo_user` to `DW_ATE_hi_user`.
-
-> NOTE: It is unclear if `DW_ATE_address` is an integral type. GDB does not seem
-> to consider it as integral.
-
-#### A.2.5.3 DWARF Location Description
-
-<i>Debugging information must provide consumers a way to find the location of
-program variables, determine the bounds of dynamic arrays and strings, and
-possibly to find the base address of a subprogram's call frame or the return
-address of a subprogram. Furthermore, to meet the needs of recent computer
-architectures and optimization techniques, debugging information must be able to
-describe the location of an object whose location changes over the object's
-lifetime, and may reside at multiple locations simultaneously during parts of an
-object's lifetime.</i>
-
-Information about the location of program objects is provided by location
-descriptions.
-
-Location descriptions can consist of one or more single location descriptions.
-
-A single location description specifies the location storage that holds a
-program object and a position within the location storage where the program
-object starts. The position within the location storage is expressed as a bit
-offset relative to the start of the location storage.
-
-A location storage is a linear stream of bits that can hold values. Each
-location storage has a size in bits and can be accessed using a zero-based bit
-offset. The ordering of bits within a location storage uses the bit numbering
-and direction conventions that are appropriate to the current language on the
-target architecture.
-
-There are five kinds of location storage:
-
-1.  <i>memory location storage</i>
-
-    Corresponds to the target architecture memory address spaces.
-
-2.  <i>register location storage</i>
-
-    Corresponds to the target architecture registers.
-
-3.  <i>implicit location storage</i>
-
-    Corresponds to fixed values that can only be read.
-
-4.  <i>undefined location storage</i>
-
-    Indicates no value is available and therefore cannot be read or written.
-
-5.  <i>composite location storage</i>
-
-    Allows a mixture of these where some bits come from one location storage and
-    some from another location storage, or from disjoint parts of the same
-    location storage.
-
-> NOTE: It may be better to add an implicit pointer location storage kind used
-> by the `DW_OP_implicit_pointer` operation. It would specify the debugger
-> information entry and byte offset provided by the operations.
-
-<i>Location descriptions are a language independent representation of addressing
-rules.</i>
-
-- <i>They can be the result of evaluating a debugger information entry attribute
-  that specifies an operation expression of arbitrary complexity. In this usage
-  they can describe the location of an object as long as its lifetime is either
-  static or the same as the lexical block (see [3.5 Lexical Block
-  Entries](#lexical-block-entries)) that owns it, and it does not move during
-  its lifetime.</i>
-
-- <i>They can be the result of evaluating a debugger information entry attribute
-  that specifies a location list expression. In this usage they can describe the
-  location of an object that has a limited lifetime, changes its location during
-  its lifetime, or has multiple locations over part or all of its lifetime.</i>
-
-If a location description has more than one single location description, the
-DWARF expression is ill-formed if the object value held in each single location
-description's position within the associated location storage is not the same
-value, except for the parts of the value that are uninitialized.
-
-<i>A location description that has more than one single location description can
-only be created by a location list expression that has overlapping program
-location ranges, or certain expression operations that act on a location
-description that has more than one single location description. There are no
-operation expression operations that can directly create a location description
-with more than one single location description.</i>
-
-<i>A location description with more than one single location description can be
-used to describe objects that reside in more than one piece of storage at the
-same time. An object may have more than one location as a result of
-optimization. For example, a value that is only read may be promoted from memory
-to a register for some region of code, but later code may revert to reading the
-value from memory as the register may be used for other purposes. For the code
-region where the value is in a register, any change to the object value must be
-made in both the register and the memory so both regions of code will read the
-updated value.</i>
-
-<i>A consumer of a location description with more than one single location
-description can read the object's value from any of the single location
-descriptions (since they all refer to location storage that has the same value),
-but must write any changed value to all the single location descriptions.</i>
-
-Updating a location description L by a bit offset B is defined as adding the
-value of B to the bit offset of each single location description SL of L. It is
-an evaluation error if the updated bit offset of any SL is less than 0 or
-greater than or equal to the size of the location storage specified by SL.
-
-The evaluation of an expression may require context elements to create a
-location description. If such a location description is accessed, the storage it
-denotes is that associated with the context element values specified when the
-location description was created, which may differ from the context at the time
-it is accessed.
-
-<i>For example, creating a register location description requires the thread
-context: the location storage is for the specified register of that thread.
-Creating a memory location description for an address space may required a
-thread context: the location storage is the memory associated with that
-thread.</i>
-
-If any of the context elements required to create a location description change,
-the location description becomes invalid and accessing it is undefined.
-
-<i>Examples of context that can invalidate a location description are:</i>
-
-- <i>The thread context is required and execution causes the thread to
-  terminate.</i>
-- <i>The call frame context is required and further execution causes the call
-  frame to return to the calling frame.</i>
-- <i>The program location is required and further execution of the thread
-  occurs. That could change the location list entry or call frame information
-  entry that applies.</i>
-- <i>An operation uses call frame information:</i>
-  - <i>Any of the frames used in the virtual call frame unwinding return.</i>
-  - <i>The top call frame is used, the program location is used to select the
-    call frame information entry, and further execution of the thread
-    occurs.</i>
-
-<i>A DWARF expression can be used to compute a location description for an
-object. A subsequent DWARF expression evaluation can be given the object
-location description as the object context or initial stack context to compute a
-component of the object. The final result is undefined if the object location
-description becomes invalid between the two expression evaluations.</i>
-
-A change of a thread's program location may not make a location description
-invalid, yet may still render it as no longer meaningful. Accessing such a
-location description, or using it as the object context or initial stack context
-of an expression evaluation, may produce an undefined result.
-
-<i>For example, a location description may specify a register that no longer
-holds the intended program object after a program location change. One way to
-avoid such problems is to recompute location descriptions associated with
-threads when their program locations change.</i>
-
-#### A.2.5.4 DWARF Operation Expressions
-
-An operation expression is comprised of a stream of operations, each consisting
-of an opcode followed by zero or more operands. The number of operands is
-implied by the opcode.
-
-Operations represent a postfix operation on a simple stack machine. Each stack
-entry can hold either a value or a location description. Operations can act on
-entries on the stack, including adding entries and removing entries. If the kind
-of a stack entry does not match the kind required by the operation and is not
-implicitly convertible to the required kind (see [2.5.4.4.3 Memory Location
-Description Operations](#memory-location-description-operations)), then
-the DWARF operation expression is ill-formed.
-
-Evaluation of an operation expression starts with an empty stack on which the
-entries from the initial stack provided by the context are pushed in the order
-provided. Then the operations are evaluated, starting with the first operation
-of the stream. Evaluation continues until either an operation has an evaluation
-error, or until one past the last operation of the stream is reached.
-
-The result of the evaluation is:
-
-- If an operation has an evaluation error, or an operation evaluates an
-  expression that has an evaluation error, then the result is an evaluation
-  error.
-- If the current result kind specifies a location description, then:
-  - If the stack is empty, the result is a location description with one
-    undefined location description.
-
-    <i>This rule is for backwards compatibility with DWARF Version 5 which uses
-    an empty operation expression for this purpose.</i>
-
-  - If the top stack entry is a location description, or can be converted to one
-    (see [2.5.4.4.3 Memory Location Description
-    Operations](#memory-location-description-operations)), then the result
-    is that, possibly converted, location description. Any other entries on the
-    stack are discarded.
-  - Otherwise the DWARF expression is ill-formed.
-
-    > NOTE: Could define this case as returning an implicit location description
-    > as if the `DW_OP_implicit` operation is performed.
-
-- If the current result kind specifies a value, then:
-  - If the top stack entry is a value, or can be converted to one (see
-    [2.5.4.4.3 Memory Location Description
-    Operations](#memory-location-description-operations)), then the result is
-    that, possibly converted, value. Any other entries on the stack are
-    discarded.
-  - Otherwise the DWARF expression is ill-formed.
-- If the current result kind is not specified, then:
-  - If the stack is empty, the result is a location description with one
-    undefined location description.
-
-    <i>This rule is for backwards compatibility with DWARF Version 5 which uses
-    an empty operation expression for this purpose.</i>
-
-    > NOTE: This rule is consistent with the rule above for when a location
-    > description is requested. However, GDB appears to report this as an error
-    > and no GDB tests appear to cause an empty stack for this case.
-
-  - Otherwise, the top stack entry is returned. Any other entries on the stack
-    are discarded.
-
-An operation expression is encoded as a byte block with some form of prefix that
-specifies the byte count. It can be used:
-
-- as the value of a debugging information entry attribute that is encoded using
-  class `exprloc` (see [7.5.5 Classes and Forms](#classes-and-forms)),
-- as the operand to certain operation expression operations,
-- as the operand to certain call frame information operations (see [6.4 Call
-  Frame Information](#call-frame-information)),
-- and in location list entries (see [2.5.5 DWARF Location List
-  Expressions](#dwarf-location-list-expressions)).
-
-##### A.2.5.4.1 Stack Operations
-
-> NOTE: This section replaces DWARF Version 5 section 2.5.1.3.
-
-The following operations manipulate the DWARF stack. Operations that index the
-stack assume that the top of the stack (most recently added entry) has index 0.
-They allow the stack entries to be either a value or location description.
-
-If any stack entry accessed by a stack operation is an incomplete composite
-location description (see [2.5.4.4.6 Composite Location Description
-Operations](#composite-location-description-operations)), then the DWARF
-expression is ill-formed.
-
-> NOTE: These operations now support stack entries that are values and location
-> descriptions.
-
-> NOTE: If it is desired to also make them work with incomplete composite
-> location descriptions, then would need to define that the composite location
-> storage specified by the incomplete composite location description is also
-> replicated when a copy is pushed. This ensures that each copy of the
-> incomplete composite location description can update the composite location
-> storage they specify independently.
-
-1.  `DW_OP_dup`
-
-    `DW_OP_dup` duplicates the stack entry at the top of the stack.
-
-2.  `DW_OP_drop`
-
-    `DW_OP_drop` pops the stack entry at the top of the stack and discards it.
-
-3.  `DW_OP_pick`
-
-    `DW_OP_pick` has a single unsigned 1-byte operand that represents an index
-    I.  A copy of the stack entry with index I is pushed onto the stack.
-
-4.  `DW_OP_over`
-
-    `DW_OP_over` pushes a copy of the entry with index 1.
-
-    <i>This is equivalent to a `DW_OP_pick 1` operation.</i>
-
-5.  `DW_OP_swap`
-
-    `DW_OP_swap` swaps the top two stack entries. The entry at the top of the
-    stack becomes the second stack entry, and the second stack entry becomes the
-    top of the stack.
-
-6.  `DW_OP_rot`
-
-    `DW_OP_rot` rotates the first three stack entries. The entry at the top of
-    the stack becomes the third stack entry, the second entry becomes the top of
-    the stack, and the third entry becomes the second entry.
-
-##### A.2.5.4.2 Control Flow Operations
-
-> NOTE: This section replaces DWARF Version 5 section 2.5.1.5.
-
-The following operations provide simple control of the flow of a DWARF operation
-expression.
-
-1.  `DW_OP_nop`
-
-    `DW_OP_nop` is a place holder. It has no effect on the DWARF stack entries.
-
-2.  `DW_OP_le`, `DW_OP_ge`, `DW_OP_eq`, `DW_OP_lt`, `DW_OP_gt`,
-    `DW_OP_ne`
-
-    > NOTE: The same as in DWARF Version 5 section 2.5.1.5.
-
-3.  `DW_OP_skip`
-
-    `DW_OP_skip` is an unconditional branch. Its single operand is a 2-byte
-    signed integer constant. The 2-byte constant is the number of bytes of the
-    DWARF expression to skip forward or backward from the current operation,
-    beginning after the 2-byte constant.
-
-    If the updated position is at one past the end of the last operation, then
-    the operation expression evaluation is complete.
-
-    Otherwise, the DWARF expression is ill-formed if the updated operation
-    position is not in the range of the first to last operation inclusive, or
-    not at the start of an operation.
-
-4.  `DW_OP_bra`
-
-    `DW_OP_bra` is a conditional branch. Its single operand is a 2-byte signed
-    integer constant. This operation pops the top of stack. If the value popped
-    is not the constant 0, the 2-byte constant operand is the number of bytes of
-    the DWARF operation expression to skip forward or backward from the current
-    operation, beginning after the 2-byte constant.
-
-    If the updated position is at one past the end of the last operation, then
-    the operation expression evaluation is complete.
-
-    Otherwise, the DWARF expression is ill-formed if the updated operation
-    position is not in the range of the first to last operation inclusive, or
-    not at the start of an operation.
-
-5.  `DW_OP_call2, DW_OP_call4, DW_OP_call_ref`
-
-    `DW_OP_call2`, `DW_OP_call4`, and `DW_OP_call_ref` perform DWARF procedure
-    calls during evaluation of a DWARF expression.
-
-    `DW_OP_call2` and `DW_OP_call4`, have one operand that is, respectively, a
-    2-byte or 4-byte unsigned offset DR that represents the byte offset of a
-    debugging information entry D relative to the beginning of the current
-    compilation unit.
-
-    `DW_OP_call_ref` has one operand that is a 4-byte unsigned value in the
-    32-bit DWARF format, or an 8-byte unsigned value in the 64-bit DWARF format,
-    that represents the byte offset DR of a debugging information entry D
-    relative to the beginning of the `.debug_info` section that contains the
-    current compilation unit. D may not be in the current compilation unit.
-
-    > NOTE: DWARF Version 5 states that DR can be an offset in a `.debug_info`
-    > section other than the one that contains the current compilation unit. It
-    > states that relocation of references from one executable or shared object
-    > file to another must be performed by the consumer. But given that DR is
-    > defined as an offset in a `.debug_info` section this seems impossible. If
-    > DR was defined as an implementation defined value, then the consumer could
-    > choose to interpret the value in an implementation defined manner to
-    > reference a debug information in another executable or shared object.
-    >
-    > In ELF the `.debug_info` section is in a non-`PT_LOAD` segment so standard
-    > dynamic relocations cannot be used. But even if they were loaded segments
-    > and dynamic relocations were used, DR would need to be the address of D,
-    > not an offset in a `.debug_info` section. That would also need DR to be
-    > the size of a global address. So it would not be possible to use the
-    > 32-bit DWARF format in a 64-bit global address space. In addition, the
-    > consumer would need to determine what executable or shared object the
-    > relocated address was in so it could determine the containing compilation
-    > unit.
-    >
-    > GDB only interprets DR as an offset in the `.debug_info` section that
-    > contains the current compilation unit.
-    >
-    > This comment also applies to `DW_OP_implicit_pointer`.
-
-    <i>Operand interpretation of `DW_OP_call2`, `DW_OP_call4`, and
-    `DW_OP_call_ref` is exactly like that for `DW_FORM_ref2`, `DW_FORM_ref4`,
-    and `DW_FORM_ref_addr`, respectively.</i>
-
-    The call operation is evaluated by:
-
-    - If D has a `DW_AT_location` attribute that is encoded as a `exprloc` that
-      specifies an operation expression E, then execution of the current
-      operation expression continues from the first operation of E. Execution
-      continues until one past the last operation of E is reached, at which
-      point execution continues with the operation following the call operation.
-      The operations of E are evaluated with the same current context, except
-      current compilation unit is the one that contains D and the stack is the
-      same as that being used by the call operation. After the call operation
-      has been evaluated, the stack is therefore as it is left by the evaluation
-      of the operations of E. Since E is evaluated on the same stack as the call
-      operation, E can use, and/or remove entries already on the stack, and can
-      add new entries to the stack.
-
-      <i>Values on the stack at the time of the call may be used as parameters
-      by the called expression and values left on the stack by the called
-      expression may be used as return values by prior agreement between the
-      calling and called expressions.</i>
-
-    - If D has a `DW_AT_location` attribute that is encoded as a `loclist` or
-      `loclistsptr`, then the specified location list expression E is evaluated.
-      The evaluation of E uses the current context, except the result kind is a
-      location description, the compilation unit is the one that contains D, and
-      the initial stack is empty. The location description result is pushed on
-      the stack.
-
-      > NOTE: This rule avoids having to define how to execute a matched
-      > location list entry operation expression on the same stack as the call
-      > when there are multiple matches. But it allows the call to obtain the
-      > location description for a variable or formal parameter which may use a
-      > location list expression.
-      >
-      > An alternative is to treat the case when D has a `DW_AT_location`
-      > attribute that is encoded as a `loclist` or `loclistsptr`, and the
-      > specified location list expression E' matches a single location list
-      > entry with operation expression E, the same as the `exprloc` case and
-      > evaluate on the same stack.
-      >
-      > But this is not attractive as if the attribute is for a variable that
-      > happens to end with a non-singleton stack, it will not simply put a
-      > location description on the stack. Presumably the intent of using
-      > `DW_OP_call*` on a variable or formal parameter debugger information
-      > entry is to push just one location description on the stack. That
-      > location description may have more than one single location description.
-      >
-      > The previous rule for `exprloc` also has the same problem, as normally a
-      > variable or formal parameter location expression may leave multiple
-      > entries on the stack and only return the top entry.
-      >
-      > GDB implements `DW_OP_call*` by always executing E on the same stack. If
-      > the location list has multiple matching entries, it simply picks the
-      > first one and ignores the rest. This seems fundamentally at odds with
-      > the desire to support multiple places for variables.
-      >
-      > So, it feels like `DW_OP_call*` should both support pushing a location
-      > description on the stack for a variable or formal parameter, and also
-      > support being able to execute an operation expression on the same stack.
-      > Being able to specify a different operation expression for different
-      > program locations seems a desirable feature to retain.
-      >
-      > A solution to that is to have a distinct `DW_AT_proc` attribute for the
-      > `DW_TAG_dwarf_procedure` debugging information entry. Then the
-      > `DW_AT_location` attribute expression is always executed separately and
-      > pushes a location description (that may have multiple single location
-      > descriptions), and the `DW_AT_proc` attribute expression is always
-      > executed on the same stack and can leave anything on the stack.
-      >
-      > The `DW_AT_proc` attribute could have the new classes `exprproc`,
-      > `loclistproc`, and `loclistsptrproc` to indicate that the expression is
-      > executed on the same stack. `exprproc` is the same encoding as
-      > `exprloc`. `loclistproc` and `loclistsptrproc` are the same encoding as
-      > their non-`proc` counterparts, except the DWARF is ill-formed if the
-      > location list does not match exactly one location list entry and a
-      > default entry is required. These forms indicate explicitly that the
-      > matched single operation expression must be executed on the same stack.
-      > This is better than ad hoc special rules for `loclistproc` and
-      > `loclistsptrproc` which are currently clearly defined to always return a
-      > location description. The producer then explicitly indicates the intent
-      > through the attribute classes.
-      >
-      > Such a change would be a breaking change for how GDB implements
-      > `DW_OP_call*`. However, are the breaking cases actually occurring in
-      > practice? GDB could implement the current approach for DWARF Version 5,
-      > and the new semantics for DWARF Version 6 which has been done for some
-      > other features.
-      >
-      > Another option is to limit the execution to be on the same stack only to
-      > the evaluation of an expression E that is the value of a
-      > `DW_AT_location` attribute of a `DW_TAG_dwarf_procedure` debugging
-      > information entry. The DWARF would be ill-formed if E is a location list
-      > expression that does not match exactly one location list entry. In all
-      > other cases the evaluation of an expression E that is the value of a
-      > `DW_AT_location` attribute would evaluate E with the current context,
-      > except the result kind is a location description, the compilation unit
-      > is the one that contains D, and the initial stack is empty. The location
-      > description result is pushed on the stack.
-
-    - If D has a `DW_AT_const_value` attribute with a value V, then it is as if
-      a `DW_OP_implicit_value V` operation was executed.
-
-      <i>This allows a call operation to be used to compute the location
-      description for any variable or formal parameter regardless of whether the
-      producer has optimized it to a constant. This is consistent with the
-      `DW_OP_implicit_pointer` operation.</i>
-
-      > NOTE: Alternatively, could deprecate using `DW_AT_const_value` for
-      > `DW_TAG_variable` and `DW_TAG_formal_parameter` debugger information
-      > entries that are constants and instead use `DW_AT_location` with an
-      > operation expression that results in a location description with one
-      > implicit location description. Then this rule would not be required.
-
-    - Otherwise, there is no effect and no changes are made to the stack.
-
-      > NOTE: In DWARF Version 5, if D does not have a `DW_AT_location` then
-      > `DW_OP_call*` is defined to have no effect. It is unclear that this is
-      > the right definition as a producer should be able to rely on using
-      > `DW_OP_call*` to get a location description for any
-      > non-`DW_TAG_dwarf_procedure` debugging information entries. Also, the
-      > producer should not be creating DWARF with `DW_OP_call*` to a
-      > `DW_TAG_dwarf_procedure` that does not have a `DW_AT_location`
-      > attribute. So, should this case be defined as an ill-formed DWARF
-      > expression?
-
-    <i>The `DW_TAG_dwarf_procedure` debugging information entry can be used to
-    define DWARF procedures that can be called.</i>
-
-##### A.2.5.4.3 Value Operations
-
-This section describes the operations that push values on the stack.
-
-Each value stack entry has a type and a literal value. It can represent a
-literal value of any supported base type of the target architecture. The base
-type specifies the size, encoding, and endianity of the literal value.
-
-The base type of value stack entries can be the distinguished generic type.
-
-###### A.2.5.4.3.1 Literal Operations
-
-> NOTE: This section replaces DWARF Version 5 section 2.5.1.1.
-
-The following operations all push a literal value onto the DWARF stack.
-
-Operations other than `DW_OP_const_type` push a value V with the generic type.
-If V is larger than the generic type, then V is truncated to the generic type
-size and the low-order bits used.
-
-1.  `DW_OP_lit0`, `DW_OP_lit1`, ..., `DW_OP_lit31`
-
-    `DW_OP_lit<N>` operations encode an unsigned literal value N from 0 through
-    31, inclusive. They push the value N with the generic type.
-
-2.  `DW_OP_const1u`, `DW_OP_const2u`, `DW_OP_const4u`, `DW_OP_const8u`
-
-    `DW_OP_const<N>u` operations have a single operand that is a 1, 2, 4, or
-    8-byte unsigned integer constant U, respectively. They push the value U with
-    the generic type.
-
-3.  `DW_OP_const1s`, `DW_OP_const2s`, `DW_OP_const4s`, `DW_OP_const8s`
-
-    `DW_OP_const<N>s` operations have a single operand that is a 1, 2, 4, or
-    8-byte signed integer constant S, respectively. They push the value S with
-    the generic type.
-
-4.  `DW_OP_constu`
-
-    `DW_OP_constu` has a single unsigned LEB128 integer operand N. It pushes the
-    value N with the generic type.
-
-5.  `DW_OP_consts`
-
-    `DW_OP_consts` has a single signed LEB128 integer operand N. It pushes the
-    value N with the generic type.
-
-6.  `DW_OP_constx`
-
-    `DW_OP_constx` has a single unsigned LEB128 integer operand that represents
-    a zero-based index into the `.debug_addr` section relative to the value of
-    the `DW_AT_addr_base` attribute of the associated compilation unit. The
-    value N in the `.debug_addr` section has the size of the generic type. It
-    pushes the value N with the generic type.
-
-    <i>The `DW_OP_constx` operation is provided for constants that require
-    link-time relocation but should not be interpreted by the consumer as a
-    relocatable address (for example, offsets to thread-local storage).</i>
-
-7.  `DW_OP_const_type`
-
-    `DW_OP_const_type` has three operands. The first is an unsigned LEB128
-    integer DR that represents the byte offset of a debugging information entry
-    D relative to the beginning of the current compilation unit, that provides
-    the type T of the constant value. The second is a 1-byte unsigned integral
-    constant S. The third is a block of bytes B, with a length equal to S.
-
-    TS is the bit size of the type T. The least significant TS bits of B are
-    interpreted as a value V of the type D. It pushes the value V with the type
-    D.
-
-    The DWARF is ill-formed if D is not a `DW_TAG_base_type` debugging
-    information entry in the current compilation unit, or if TS divided by 8
-    (the byte size) and rounded up to a whole number is not equal to S.
-
-    <i>While the size of the byte block B can be inferred from the type D
-    definition, it is encoded explicitly into the operation so that the
-    operation can be parsed easily without reference to the `.debug_info`
-    section.</i>
-
-###### A.2.5.4.3.2 Arithmetic and Logical Operations
-
-> NOTE: This section is the same as DWARF Version 5 section 2.5.1.4.
-
-###### A.2.5.4.3.3 Type Conversion Operations
-
-> NOTE: This section is the same as DWARF Version 5 section 2.5.1.6.
-
-###### A.2.5.4.3.4 Special Value Operations
-
-> NOTE: This section replaces parts of DWARF Version 5 sections 2.5.1.2,
-  2.5.1.3, and 2.5.1.7.
-
-There are these special value operations currently defined:
-
-1.  `DW_OP_regval_type`
-
-    `DW_OP_regval_type` has two operands. The first is an unsigned LEB128
-    integer that represents a register number R. The second is an unsigned
-    LEB128 integer DR that represents the byte offset of a debugging information
-    entry D relative to the beginning of the current compilation unit, that
-    provides the type T of the register value.
-
-    The operation is equivalent to performing `DW_OP_regx R; DW_OP_deref_type
-    DR`.
-
-    > NOTE: Should DWARF allow the type T to be a larger size than the size of
-    > the register R? Restricting a larger bit size avoids any issue of
-    > conversion as the, possibly truncated, bit contents of the register is
-    > simply interpreted as a value of T. If a conversion is wanted it can be
-    > done explicitly using a `DW_OP_convert` operation.
-    >
-    > GDB has a per register hook that allows a target specific conversion on a
-    > register by register basis. It defaults to truncation of bigger registers.
-    > Removing use of the target hook does not cause any test failures in common
-    > architectures. If the compiler for a target architecture did want some
-    > form of conversion, including a larger result type, it could always
-    > explicitly used the `DW_OP_convert` operation.
-    >
-    > If T is a larger type than the register size, then the default GDB
-    > register hook reads bytes from the next register (or reads out of bounds
-    > for the last register!). Removing use of the target hook does not cause
-    > any test failures in common architectures (except an illegal hand written
-    > assembly test). If a target architecture requires this behavior, these
-    > extensions allow a composite location description to be used to combine
-    > multiple registers.
-
-2.  `DW_OP_deref`
-
-    S is the bit size of the generic type divided by 8 (the byte size) and
-    rounded up to a whole number. DR is the offset of a hypothetical debug
-    information entry D in the current compilation unit for a base type of the
-    generic type.
-
-    The operation is equivalent to performing `DW_OP_deref_type S, DR`.
-
-3.  `DW_OP_deref_size`
-
-    `DW_OP_deref_size` has a single 1-byte unsigned integral constant that
-    represents a byte result size S.
-
-    TS is the smaller of the generic type bit size and S scaled by 8 (the byte
-    size). If TS is smaller than the generic type bit size then T is an unsigned
-    integral type of bit size TS, otherwise T is the generic type. DR is the
-    offset of a hypothetical debug information entry D in the current
-    compilation unit for a base type T.
-
-    > NOTE: Truncating the value when S is larger than the generic type matches
-    > what GDB does. This allows the generic type size to not be an integral
-    > byte size. It does allow S to be arbitrarily large. Should S be restricted
-    > to the size of the generic type rounded up to a multiple of 8?
-
-    The operation is equivalent to performing `DW_OP_deref_type S, DR`, except
-    if T is not the generic type, the value V pushed is zero-extended to the
-    generic type bit size and its type changed to the generic type.
-
-4.  `DW_OP_deref_type`
-
-    `DW_OP_deref_type` has two operands. The first is a 1-byte unsigned integral
-    constant S. The second is an unsigned LEB128 integer DR that represents the
-    byte offset of a debugging information entry D relative to the beginning of
-    the current compilation unit, that provides the type T of the result value.
-
-    TS is the bit size of the type T.
-
-    <i>While the size of the pushed value V can be inferred from the type T, it
-    is encoded explicitly as the operand S so that the operation can be parsed
-    easily without reference to the `.debug_info` section.</i>
-
-    > NOTE: It is unclear why the operand S is needed. Unlike
-    > `DW_OP_const_type`, the size is not needed for parsing. Any evaluation
-    > needs to get the base type T to push with the value to know its encoding
-    > and bit size.
-
-    It pops one stack entry that must be a location description L.
-
-    A value V of TS bits is retrieved from the location storage LS specified by
-    one of the single location descriptions SL of L.
-
-    <i>If L, or the location description of any composite location description
-    part that is a subcomponent of L, has more than one single location
-    description, then any one of them can be selected as they are required to
-    all have the same value. For any single location description SL, bits are
-    retrieved from the associated storage location starting at the bit offset
-    specified by SL. For a composite location description, the retrieved bits
-    are the concatenation of the N bits from each composite location part PL,
-    where N is limited to the size of PL.</i>
-
-    V is pushed on the stack with the type T.
-
-    > NOTE: This definition makes it an evaluation error if L is a register
-    > location description that has less than TS bits remaining in the register
-    > storage. Particularly since these extensions extend location descriptions
-    > to have a bit offset, it would be odd to define this as performing sign
-    > extension based on the type, or be target architecture dependent, as the
-    > number of remaining bits could be any number. This matches the GDB
-    > implementation for `DW_OP_deref_type`.
-    >
-    > These extensions define `DW_OP_*breg*` in terms of `DW_OP_regval_type`.
-    > `DW_OP_regval_type` is defined in terms of `DW_OP_regx`, which uses a 0
-    > bit offset, and `DW_OP_deref_type`. Therefore, it requires the register
-    > size to be greater or equal to the address size of the address space. This
-    > matches the GDB implementation for `DW_OP_*breg*`.
-
-    The DWARF is ill-formed if D is not in the current compilation unit, D is
-    not a `DW_TAG_base_type` debugging information entry, or if TS divided by 8
-    (the byte size) and rounded up to a whole number is not equal to S.
-
-    > NOTE: This definition allows the base type to be a bit size since there
-    > seems no reason to restrict it.
-
-    It is an evaluation error if any bit of the value is retrieved from the
-    undefined location storage or the offset of any bit exceeds the size of the
-    location storage LS specified by any single location description SL of L.
-
-    See [2.5.4.4.5 Implicit Location Description
-    Operations](#implicit-location-description-operations) for special
-    rules concerning implicit location descriptions created by the
-    `DW_OP_implicit_pointer` operation.
-
-5.  `DW_OP_xderef`
-
-    `DW_OP_xderef` pops two stack entries. The first must be an integral type
-    value that represents an address A. The second must be an integral type
-    value that represents a target architecture specific address space
-    identifier AS.
-
-    The address size S is defined as the address bit size of the target
-    architecture specific address space that corresponds to AS.
-
-    A is adjusted to S bits by zero extending if necessary, and then treating
-    the least significant S bits as an unsigned value A'.
-
-    It creates a location description L with one memory location description SL.
-    SL specifies the memory location storage LS that corresponds to AS with a
-    bit offset equal to A' scaled by 8 (the byte size).
-
-    If AS is an address space that is specific to context elements, then LS
-    corresponds to the location storage associated with the current context.
-
-    <i>For example, if AS is for per thread storage then LS is the location
-    storage for the current thread. Therefore, if L is accessed by an operation,
-    the location storage selected when the location description was created is
-    accessed, and not the location storage associated with the current context
-    of the access operation.</i>
-
-    The DWARF expression is ill-formed if AS is not one of the values defined by
-    the target architecture specific `DW_ASPACE_*` values.
-
-    The operation is equivalent to popping A and AS, pushing L, and then
-    performing `DW_OP_deref`. The value V retrieved is left on the stack with
-    the generic type.
-
-6.  `DW_OP_xderef_size`
-
-    `DW_OP_xderef_size` has a single 1-byte unsigned integral constant that
-    represents a byte result size S.
-
-    It pops two stack entries. The first must be an integral type value
-    that represents an address A. The second must be an integral type
-    value that represents a target architecture specific address space
-    identifier AS.
-
-    It creates a location description L as described for `DW_OP_xderef`.
-
-    The operation is equivalent to popping A and AS, pushing L, and then
-    performing `DW_OP_deref_size S` . The zero-extended value V retrieved is
-    left on the stack with the generic type.
-
-7.  `DW_OP_xderef_type`
-
-    `DW_OP_xderef_type` has two operands. The first is a 1-byte unsigned
-    integral constant S. The second operand is an unsigned LEB128 integer DR
-    that represents the byte offset of a debugging information entry D relative
-    to the beginning of the current compilation unit, that provides the type T
-    of the result value.
-
-    It pops two stack entries. The first must be an integral type value that
-    represents an address A. The second must be an integral type value that
-    represents a target architecture specific address space identifier AS.
-
-    It creates a location description L as described for `DW_OP_xderef`.
-
-    The operation is equivalent to popping A and AS, pushing L, and then
-    performing `DW_OP_deref_type DR` . The value V retrieved is left on the
-    stack with the type T.
-
-8.  `DW_OP_entry_value` <i>Deprecated</i>
-
-    `DW_OP_entry_value` pushes the value of an expression that is evaluated in
-    the context of the calling frame.
-
-    <i>It may be used to determine the value of arguments on entry to the
-    current call frame provided they are not clobbered.</i>
-
-    It has two operands. The first is an unsigned LEB128 integer S. The second
-    is a block of bytes, with a length equal S, interpreted as a DWARF operation
-    expression E.
-
-    E is evaluated with the current context, except the result kind is
-    unspecified, the call frame is the one that called the current frame, the
-    program location is the call site in the calling frame, the object is
-    unspecified, and the initial stack is empty. The calling frame information
-    is obtained by virtually unwinding the current call frame using the call
-    frame information (see [6.4 Call Frame
-    Information](#call-frame-information)).
-
-    If the result of E is a location description L (see [2.5.4.4.4 Register
-    Location Description
-    Operations](#register-location-description-operations)), and the last
-    operation executed by E is a `DW_OP_reg*` for register R with a target
-    architecture specific base type of T, then the contents of the register are
-    retrieved as if a `DW_OP_deref_type DR` operation was performed where DR is
-    the offset of a hypothetical debug information entry in the current
-    compilation unit for T. The resulting value V s pushed on the stack.
-
-    <i>Using `DW_OP_reg*` provides a more compact form for the case where the
-    value was in a register on entry to the subprogram.</i>
-
-    > NOTE: It is unclear how this provides a more compact expression, as
-    > `DW_OP_regval_type` could be used which is marginally larger.
-
-    If the result of E is a value V, then V is pushed on the stack.
-
-    Otherwise, the DWARF expression is ill-formed.
-
-    <i>The `DW_OP_entry_value` operation is deprecated as its main usage is
-    provided by other means. DWARF Version 5 added the
-    `DW_TAG_call_site_parameter` debugger information entry for call sites that
-    has `DW_AT_call_value`, `DW_AT_call_data_location`, and
-    `DW_AT_call_data_value` attributes that provide DWARF expressions to compute
-    actual parameter values at the time of the call, and requires the producer
-    to ensure the expressions are valid to evaluate even when virtually
-    unwound.</i>
-
-    > NOTE: GDB only implements `DW_OP_entry_value` when E is exactly
-    > `DW_OP_reg*` or `DW_OP_breg*; DW_OP_deref*`.
-
-##### A.2.5.4.4 Location Description Operations
-
-This section describes the operations that push location descriptions on the
-stack.
-
-###### A.2.5.4.4.1 General Location Description Operations
-
-> NOTE: This section replaces part of DWARF Version 5 section 2.5.1.3.
-
-1.  `DW_OP_push_object_address`
-
-    `DW_OP_push_object_address` pushes the location description L of the current
-    object.
-
-    <i>This object may correspond to an independent variable that is part of a
-    user presented expression that is being evaluated. The object location
-    description may be determined from the variable's own debugging information
-    entry or it may be a component of an array, structure, or class whose
-    address has been dynamically determined by an earlier step during user
-    expression evaluation.</i>
-
-    <i>This operation provides explicit functionality (especially for arrays
-    involving descriptors) that is analogous to the implicit push of the base
-    location description of a structure prior to evaluation of a
-    `DW_AT_data_member_location` to access a data member of a structure.</i>
-
-    > NOTE: This operation could be removed and the object location description
-    > specified as the initial stack as for `DW_AT_data_member_location`.
-    >
-    > Or this operation could be used instead of needing to specify an initial
-    > stack. The latter approach is more composable as access to the object may
-    > be needed at any point of the expression, and passing it as the initial
-    > stack requires the entire expression to be aware where on the stack it is.
-    > If this were done, ``DW_AT_use_location`` would require a
-    > ``DW_OP_push_object2_address`` operation for the second object.
-    >
-    > Or a more general way to pass an arbitrary number of arguments in and an
-    > operation to get the Nth one such as ``DW_OP_arg N``. A vector of
-    > arguments would then be passed in the expression context rather than an
-    > initial stack. This could also resolve the issues with ``DW_OP_call*`` by
-    > allowing a specific number of arguments passed in and returned to be
-    > specified. The ``DW_OP_call*`` operation could then always execute on a
-    > separate stack: the number of arguments would be specified in a new call
-    > operation and taken from the callers stack, and similarly the number of
-    > return results specified and copied from the called stack back to the
-    > callee stack when the called expression was complete.
-    >
-    > The only attribute that specifies a current object is
-    > `DW_AT_data_location` so the non-normative text seems to overstate how
-    > this is being used. Or are there other attributes that need to state they
-    > pass an object?
-
-###### A.2.5.4.4.2 Undefined Location Description Operations
-
-> NOTE: This section replaces DWARF Version 5 section 2.6.1.1.1.
-
-<i>The undefined location storage represents a piece or all of an object that is
-present in the source but not in the object code (perhaps due to optimization).
-Neither reading nor writing to the undefined location storage is meaningful.</i>
-
-An undefined location description specifies the undefined location storage.
-There is no concept of the size of the undefined location storage, nor of a bit
-offset for an undefined location description. The `DW_OP_*piece` operations can
-implicitly specify an undefined location description, allowing any size and
-offset to be specified, and results in a part with all undefined bits.
-
-###### A.2.5.4.4.3 Memory Location Description Operations
-
-> NOTE: This section replaces parts of DWARF Version 5 section 2.5.1.1, 2.5.1.2,
-> 2.5.1.3, and 2.6.1.1.2.
-
-Each of the target architecture specific address spaces has a corresponding
-memory location storage that denotes the linear addressable memory of that
-address space. The size of each memory location storage corresponds to the range
-of the addresses in the corresponding address space.
-
-<i>It is target architecture defined how address space location storage maps to
-target architecture physical memory. For example, they may be independent
-memory, or more than one location storage may alias the same physical memory
-possibly at different offsets and with different interleaving. The mapping may
-also be dictated by the source language address classes.</i>
-
-A memory location description specifies a memory location storage. The bit
-offset corresponds to a bit position within a byte of the memory. Bits accessed
-using a memory location description, access the corresponding target
-architecture memory starting at the bit position within the byte specified by
-the bit offset.
-
-A memory location description that has a bit offset that is a multiple of 8 (the
-byte size) is defined to be a byte address memory location description. It has a
-memory byte address A that is equal to the bit offset divided by 8.
-
-A memory location description that does not have a bit offset that is a multiple
-of 8 (the byte size) is defined to be a bit field memory location description.
-It has a bit position B equal to the bit offset modulo 8, and a memory byte
-address A equal to the bit offset minus B that is then divided by 8.
-
-The address space AS of a memory location description is defined to be the
-address space that corresponds to the memory location storage associated with
-the memory location description.
-
-A location description that is comprised of one byte address memory location
-description SL is defined to be a memory byte address location description. It
-has a byte address equal to A and an address space equal to AS of the
-corresponding SL.
-
-`DW_ASPACE_none` is defined as the target architecture default address space.
-
-If a stack entry is required to be a location description, but it is a value V
-with the generic type, then it is implicitly converted to a location description
-L with one memory location description SL. SL specifies the memory location
-storage that corresponds to the target architecture default address space with a
-bit offset equal to V scaled by 8 (the byte size).
-
-> NOTE: If it is wanted to allow any integral type value to be implicitly
-> converted to a memory location description in the target architecture default
-> address space:
->
-> > If a stack entry is required to be a location description, but is a value V
-> > with an integral type, then it is implicitly converted to a location
-> > description L with a one memory location description SL. If the type size of
-> > V is less than the generic type size, then the value V is zero extended to
-> > the size of the generic type. The least significant generic type size bits
-> > are treated as an unsigned value to be used as an address A. SL specifies
-> > memory location storage corresponding to the target architecture default
-> > address space with a bit offset equal to A scaled by 8 (the byte size).
->
-> The implicit conversion could also be defined as target architecture specific.
-> For example, GDB checks if V is an integral type. If it is not it gives an
-> error. Otherwise, GDB zero-extends V to 64 bits. If the GDB target defines a
-> hook function, then it is called. The target specific hook function can modify
-> the 64-bit value, possibly sign extending based on the original value type.
-> Finally, GDB treats the 64-bit value V as a memory location address.
-
-If a stack entry is required to be a location description, but it is an implicit
-pointer value IPV with the target architecture default address space, then it is
-implicitly converted to a location description with one single location
-description specified by IPV. See [2.5.4.4.5 Implicit Location Description
-Operations](#implicit-location-description-operations).
-
-If a stack entry is required to be a value, but it is a location description L
-with one memory location description SL in the target architecture default
-address space with a bit offset B that is a multiple of 8, then it is implicitly
-converted to a value equal to B divided by 8 (the byte size) with the generic
-type.
-
-1.  `DW_OP_addr`
-
-    `DW_OP_addr` has a single byte constant value operand, which has the size of
-    the generic type, that represents an address A.
-
-    It pushes a location description L with one memory location description SL
-    on the stack. SL specifies the memory location storage corresponding to the
-    target architecture default address space with a bit offset equal to A
-    scaled by 8 (the byte size).
-
-    <i>If the DWARF is part of a code object, then A may need to be relocated.
-    For example, in the ELF code object format, A must be adjusted by the
-    difference between the ELF segment virtual address and the virtual address
-    at which the segment is loaded.</i>
-
-2.  `DW_OP_addrx`
-
-    `DW_OP_addrx` has a single unsigned LEB128 integer operand that represents a
-    zero-based index into the `.debug_addr` section relative to the value of the
-    `DW_AT_addr_base` attribute of the associated compilation unit. The address
-    value A in the `.debug_addr` section has the size of the generic type.
-
-    It pushes a location description L with one memory location description SL
-    on the stack. SL specifies the memory location storage corresponding to the
-    target architecture default address space with a bit offset equal to A
-    scaled by 8 (the byte size).
-
-    <i>If the DWARF is part of a code object, then A may need to be relocated.
-    For example, in the ELF code object format, A must be adjusted by the
-    difference between the ELF segment virtual address and the virtual address
-    at which the segment is loaded.</i>
-
-3.  `DW_OP_form_tls_address`
-
-    `DW_OP_form_tls_address` pops one stack entry that must be an integral type
-    value and treats it as a thread-local storage address TA.
-
-    It pushes a location description L with one memory location description SL
-    on the stack. SL is the target architecture specific memory location
-    description that corresponds to the thread-local storage address TA.
-
-    The meaning of the thread-local storage address TA is defined by the
-    run-time environment. If the run-time environment supports multiple
-    thread-local storage blocks for a single thread, then the block
-    corresponding to the executable or shared library containing this DWARF
-    expression is used.
-
-    <i>Some implementations of C, C++, Fortran, and other languages support a
-    thread-local storage class. Variables with this storage class have distinct
-    values and addresses in distinct threads, much as automatic variables have
-    distinct values and addresses in each subprogram invocation. Typically,
-    there is a single block of storage containing all thread-local variables
-    declared in the main executable, and a separate block for the variables
-    declared in each shared library. Each thread-local variable can then be
-    accessed in its block using an identifier. This identifier is typically a
-    byte offset into the block and pushed onto the DWARF stack by one of the
-    `DW_OP_const*` operations prior to the `DW_OP_form_tls_address` operation.
-    Computing the address of the appropriate block can be complex (in some
-    cases, the compiler emits a function call to do it), and difficult to
-    describe using ordinary DWARF location descriptions. Instead of forcing
-    complex thread-local storage calculations into the DWARF expressions, the
-    `DW_OP_form_tls_address` allows the consumer to perform the computation
-    based on the target architecture specific run-time environment.</i>
-
-4.  `DW_OP_call_frame_cfa`
-
-    `DW_OP_call_frame_cfa` pushes the location description L of the Canonical
-    Frame Address (CFA) of the current subprogram, obtained from the call frame
-    information on the stack. See [6.4 Call Frame
-    Information](#call-frame-information).
-
-    <i>Although the value of the `DW_AT_frame_base` attribute of the debugger
-    information entry corresponding to the current subprogram can be computed
-    using a location list expression, in some cases this would require an
-    extensive location list because the values of the registers used in
-    computing the CFA change during a subprogram execution. If the call frame
-    information is present, then it already encodes such changes, and it is
-    space efficient to reference that using the `DW_OP_call_frame_cfa`
-    operation.</i>
-
-5.  `DW_OP_fbreg`
-
-    `DW_OP_fbreg` has a single signed LEB128 integer operand that represents a
-    byte displacement B.
-
-    The location description L for the <i>frame base</i> of the current
-    subprogram is obtained from the `DW_AT_frame_base` attribute of the debugger
-    information entry corresponding to the current subprogram as described in
-    [3.3.5 Low-Level Information](#low-level-information).
-
-    The location description L is updated by bit offset B scaled by 8 (the byte
-    size) and pushed on the stack.
-
-6.  `DW_OP_breg0`, `DW_OP_breg1`, ..., `DW_OP_breg31`
-
-    The `DW_OP_breg<N>` operations encode the numbers of up to 32 registers,
-    numbered from 0 through 31, inclusive. The register number R corresponds to
-    the N in the operation name.
-
-    They have a single signed LEB128 integer operand that represents a byte
-    displacement B.
-
-    The address space identifier AS is defined as the one corresponding to the
-    target architecture specific default address space.
-
-    The address size S is defined as the address bit size of the target
-    architecture specific address space corresponding to AS.
-
-    The contents of the register specified by R are retrieved as if a
-    `DW_OP_regval_type R, DR` operation was performed where DR is the offset of
-    a hypothetical debug information entry in the current compilation unit for
-    an unsigned integral base type of size S bits. B is added and the least
-    significant S bits are treated as an unsigned value to be used as an address
-    A.
-
-    They push a location description L comprising one memory location
-    description LS on the stack. LS specifies the memory location storage that
-    corresponds to AS with a bit offset equal to A scaled by 8 (the byte size).
-
-7.  `DW_OP_bregx`
-
-    `DW_OP_bregx` has two operands. The first is an unsigned LEB128 integer that
-    represents a register number R. The second is a signed LEB128 integer that
-    represents a byte displacement B.
-
-    The action is the same as for `DW_OP_breg<N>`, except that R is used as the
-    register number and B is used as the byte displacement.
-
-###### A.2.5.4.4.4 Register Location Description Operations
-
-> NOTE: This section replaces DWARF Version 5 section 2.6.1.1.3.
-
-There is a register location storage that corresponds to each of the target
-architecture registers. The size of each register location storage corresponds
-to the size of the corresponding target architecture register.
-
-A register location description specifies a register location storage. The bit
-offset corresponds to a bit position within the register. Bits accessed using a
-register location description access the corresponding target architecture
-register starting at the specified bit offset.
-
-1.  `DW_OP_reg0`, `DW_OP_reg1`, ..., `DW_OP_reg31`
-
-    `DW_OP_reg<N>` operations encode the numbers of up to 32 registers, numbered
-    from 0 through 31, inclusive. The target architecture register number R
-    corresponds to the N in the operation name.
-
-    The operation is equivalent to performing `DW_OP_regx R`.
-
-2.  `DW_OP_regx`
-
-    `DW_OP_regx` has a single unsigned LEB128 integer operand that represents a
-    target architecture register number R.
-
-    If the current call frame is the top call frame, it pushes a location
-    description L that specifies one register location description SL on the
-    stack. SL specifies the register location storage that corresponds to R with
-    a bit offset of 0 for the current thread.
-
-    If the current call frame is not the top call frame, call frame information
-    (see [6.4 Call Frame Information](#call-frame-information)) is used to
-    determine the location description that holds the register for the current
-    call frame and current program location of the current thread. The resulting
-    location description L is pushed.
-
-    <i>Note that if call frame information is used, the resulting location
-    description may be register, memory, or undefined.</i>
-
-    <i>An implementation may evaluate the call frame information immediately, or
-    may defer evaluation until L is accessed by an operation. If evaluation is
-    deferred, R and the current context can be recorded in L. When accessed, the
-    recorded context is used to evaluate the call frame information, not the
-    current context of the access operation.</i>
-
-<i>These operations obtain a register location. To fetch the contents of a
-register, it is necessary to use `DW_OP_regval_type`, use one of the
-`DW_OP_breg*` register-based addressing operations, or use `DW_OP_deref*` on a
-register location description.</i>
-
-###### A.2.5.4.4.5 Implicit Location Description Operations
-
-> NOTE: This section replaces DWARF Version 5 section 2.6.1.1.4.
-
-Implicit location storage represents a piece or all of an object which has no
-actual location in the program but whose contents are nonetheless known, either
-as a constant or can be computed from other locations and values in the program.
-
-An implicit location description specifies an implicit location storage. The bit
-offset corresponds to a bit position within the implicit location storage. Bits
-accessed using an implicit location description, access the corresponding
-implicit storage value starting at the bit offset.
-
-1.  `DW_OP_implicit_value`
-
-    `DW_OP_implicit_value` has two operands. The first is an unsigned LEB128
-    integer that represents a byte size S. The second is a block of bytes with a
-    length equal to S treated as a literal value V.
-
-    An implicit location storage LS is created with the literal value V and a
-    size of S.
-
-    It pushes location description L with one implicit location description SL
-    on the stack. SL specifies LS with a bit offset of 0.
-
-2.  `DW_OP_stack_value`
-
-    `DW_OP_stack_value` pops one stack entry that must be a value V.
-
-    An implicit location storage LS is created with the literal value V using
-    the size, encoding, and enianity specified by V's base type.
-
-    It pushes a location description L with one implicit location description SL
-    on the stack. SL specifies LS with a bit offset of 0.
-
-    <i>The `DW_OP_stack_value` operation specifies that the object does not
-    exist in memory, but its value is nonetheless known. In this form, the
-    location description specifies the actual value of the object, rather than
-    specifying the memory or register storage that holds the value.</i>
-
-    See [2.5.4.4.5 Implicit Location Description
-    Operations](#implicit-location-description-operations) for special
-    rules concerning implicit pointer values produced by dereferencing implicit
-    location descriptions created by the `DW_OP_implicit_pointer` operation.
-
-    > NOTE: Since location descriptions are allowed on the stack, the
-    > `DW_OP_stack_value` operation no longer terminates the DWARF operation
-    > expression execution as in DWARF Version 5.
-
-3.  `DW_OP_implicit_pointer`
-
-    <i>An optimizing compiler may eliminate a pointer, while still retaining the
-    value that the pointer addressed. `DW_OP_implicit_pointer` allows a producer
-    to describe this value.</i>
-
-    <i>`DW_OP_implicit_pointer` specifies an object is a pointer to the target
-    architecture default address space that cannot be represented as a real
-    pointer, even though the value it would point to can be described. In this
-    form, the location description specifies a debugging information entry that
-    represents the actual location description of the object to which the
-    pointer would point. Thus, a consumer of the debug information would be able
-    to access the dereferenced pointer, even when it cannot access the pointer
-    itself.</i>
-
-    `DW_OP_implicit_pointer` has two operands. The first operand is a 4-byte
-    unsigned value in the 32-bit DWARF format, or an 8-byte unsigned value in
-    the 64-bit DWARF format, that represents the byte offset DR of a debugging
-    information entry D relative to the beginning of the `.debug_info` section
-    that contains the current compilation unit. The second operand is a signed
-    LEB128 integer that represents a byte displacement B.
-
-    <i>Note that D may not be in the current compilation unit.</i>
-
-    <i>The first operand interpretation is exactly like that for
-    `DW_FORM_ref_addr`.</i>
-
-    The address space identifier AS is defined as the one corresponding to the
-    target architecture specific default address space.
-
-    The address size S is defined as the address bit size of the target
-    architecture specific address space corresponding to AS.
-
-    An implicit location storage LS is created with the debugging information
-    entry D, address space AS, and size of S.
-
-    It pushes a location description L that comprises one implicit location
-    description SL on the stack. SL specifies LS with a bit offset of 0.
-
-    It is an evaluation error if a `DW_OP_deref*` operation pops a location
-    description L', and retrieves S bits, such that any retrieved bits come from
-    an implicit location storage that is the same as LS, unless both the
-    following conditions are met:
-
-    1.  All retrieved bits come from an implicit location description that
-        refers to an implicit location storage that is the same as LS.
-
-        <i>Note that all bits do not have to come from the same implicit
-        location description, as L' may involve composite location
-        descriptors.</i>
-
-    2.  The bits come from consecutive ascending offsets within their respective
-        implicit location storage.
-
-    <i>These rules are equivalent to retrieving the complete contents of LS.</i>
-
-    If both the above conditions are met, then the value V pushed by the
-    `DW_OP_deref*` operation is an implicit pointer value IPV with a target
-    architecture specific address space of AS, a debugging information entry of
-    D, and a base type of T. If AS is the target architecture default address
-    space, then T is the generic type. Otherwise, T is a target architecture
-    specific integral type with a bit size equal to S.
-
-    If IPV is either implicitly converted to a location description (only done
-    if AS is the target architecture default address space), then the resulting
-    location description RL is:
-
-    - If D has a `DW_AT_location` attribute, the DWARF expression E from the
-      `DW_AT_location` attribute is evaluated with the current context, except
-      that the result kind is a location description, the compilation unit is
-      the one that contains D, the object is unspecified, and the initial stack
-      is empty. RL is the expression result.
-
-      <i>Note that E is evaluated with the context of the expression accessing
-      IPV, and not the context of the expression that contained the
-      `DW_OP_implicit_pointer` operation that created L.</i>
-
-    - If D has a `DW_AT_const_value` attribute, then an implicit location
-      storage RLS is created from the `DW_AT_const_value` attribute's value with
-      a size matching the size of the `DW_AT_const_value` attribute's value. RL
-      comprises one implicit location description SRL. SRL specifies RLS with a
-      bit offset of 0.
-
-      > NOTE: If using `DW_AT_const_value` for variables and formal parameters
-      > is deprecated and instead `DW_AT_location` is used with an implicit
-      > location description, then this rule would not be required.
-
-    - Otherwise, it is an evaluation error.
-
-    The location description RL is updated by bit offset B scaled by 8 (the byte
-    size).
-
-    If a `DW_OP_stack_value` operation pops a value that is the same as IPV,
-    then it pushes a location description that is the same as L.
-
-    It is an evaluation error if LS or IPV is accessed in any other manner.
-
-    <i>The restrictions on how an implicit pointer location description created
-    by `DW_OP_implicit_pointer` can be used are to simplify the DWARF consumer.
-    Similarly, for an implicit pointer value created by `DW_OP_deref*` and
-    `DW_OP_stack_value`.</i>
-
-<i>Typically a `DW_OP_implicit_pointer` operation is used in a DWARF expression
-E<sub>1</sub> of a `DW_TAG_variable` or `DW_TAG_formal_parameter` debugging
-information entry D<sub>1</sub>'s `DW_AT_location` attribute. The debugging
-information entry referenced by the `DW_OP_implicit_pointer` operation is
-typically itself a `DW_TAG_variable` or `DW_TAG_formal_parameter` debugging
-information entry D<sub>2</sub> whose `DW_AT_location` attribute gives a second
-DWARF expression E<sub>2</sub>.</i>
-
-<i>D<sub>1</sub> and E<sub>1</sub> are describing the location of a pointer type
-object. D<sub>2</sub> and E<sub>2</sub> are describing the location of the
-object pointed to by that pointer object.</i>
-
-<i>However, D<sub>2</sub> may be any debugging information entry that contains a
-`DW_AT_location` or `DW_AT_const_value` attribute (for example,
-`DW_TAG_dwarf_procedure`). By using E<sub>2</sub>, a consumer can reconstruct
-the value of the object when asked to dereference the pointer described by
-E<sub>1</sub> which contains the `DW_OP_implicit_pointer` operation.</i>
-
-###### A.2.5.4.4.6 Composite Location Description Operations
-
-> NOTE: This section replaces DWARF Version 5 section 2.6.1.2.
-
-A composite location storage represents an object or value which may be
-contained in part of another location storage or contained in parts of more than
-one location storage.
-
-Each part has a part location description L and a part bit size S. L can have
-one or more single location descriptions SL. If there are more than one SL then
-that indicates that part is located in more than one place. The bits of each
-place of the part comprise S contiguous bits from the location storage LS
-specified by SL starting at the bit offset specified by SL. All the bits must be
-within the size of LS or the DWARF expression is ill-formed.
-
-A composite location storage can have zero or more parts. The parts are
-contiguous such that the zero-based location storage bit index will range over
-each part with no gaps between them. Therefore, the size of a composite location
-storage is the sum of the size of its parts. The DWARF expression is ill-formed
-if the size of the contiguous location storage is larger than the size of the
-memory location storage corresponding to the largest target architecture
-specific address space.
-
-A composite location description specifies a composite location storage. The bit
-offset corresponds to a bit position within the composite location storage.
-
-There are operations that create a composite location storage.
-
-There are other operations that allow a composite location storage to be
-incrementally created. Each part is created by a separate operation. There may
-be one or more operations to create the final composite location storage. A
-series of such operations describes the parts of the composite location storage
-that are in the order that the associated part operations are executed.
-
-To support incremental creation, a composite location storage can be in an
-incomplete state. When an incremental operation operates on an incomplete
-composite location storage, it adds a new part.
-
-A composite location description that specifies a composite location storage
-that is incomplete is termed an incomplete composite location description. A
-composite location description that specifies a composite location storage that
-is complete is termed a complete composite location description.
-
-If the top stack entry is a location description that has one incomplete
-composite location description SL after the execution of an operation expression
-has completed, SL is converted to a complete composite location description.
-
-<i>Note that this conversion does not happen after the completion of an
-operation expression that is evaluated on the same stack by the `DW_OP_call*`
-operations. Such executions are not a separate evaluation of an operation
-expression, but rather the continued evaluation of the same operation expression
-that contains the `DW_OP_call*` operation.</i>
-
-If a stack entry is required to be a location description L, but L has an
-incomplete composite location description, then the DWARF expression is
-ill-formed. The exception is for the operations involved in incrementally
-creating a composite location description as described below.
-
-<i>Note that a DWARF operation expression may arbitrarily compose composite
-location descriptions from any other location description, including those that
-have multiple single location descriptions, and those that have composite
-location descriptions.</i>
-
-<i>The incremental composite location description operations are defined to be
-compatible with the definitions in DWARF Version 5.</i>
-
-1.  `DW_OP_piece`
-
-    `DW_OP_piece` has a single unsigned LEB128 integer that represents a byte
-    size S.
-
-    The action is based on the context:
-
-    - If the stack is empty, then a location description L comprised of one
-      incomplete composite location description SL is pushed on the stack.
-
-      An incomplete composite location storage LS is created with a single part
-      P. P specifies a location description PL and has a bit size of S scaled by
-      8 (the byte size). PL is comprised of one undefined location description
-      PSL.
-
-      SL specifies LS with a bit offset of 0.
-
-    - Otherwise, if the top stack entry is a location description L comprised of
-      one incomplete composite location description SL, then the incomplete
-      composite location storage LS that SL specifies is updated to append a new
-      part P. P specifies a location description PL and has a bit size of S
-      scaled by 8 (the byte size). PL is comprised of one undefined location
-      description PSL. L is left on the stack.
-    - Otherwise, if the top stack entry is a location description or can be
-      converted to one, then it is popped and treated as a part location
-      description PL. Then:
-
-      - If the top stack entry (after popping PL) is a location description L
-        comprised of one incomplete composite location description SL, then the
-        incomplete composite location storage LS that SL specifies is updated to
-        append a new part P. P specifies the location description PL and has a
-        bit size of S scaled by 8 (the byte size). L is left on the stack.
-      - Otherwise, a location description L comprised of one
-        incomplete composite location description SL is pushed on
-        the stack.
-
-        An incomplete composite location storage LS is created with a single
-        part P. P specifies the location description PL and has a bit size of S
-        scaled by 8 (the byte size).
-
-        SL specifies LS with a bit offset of 0.
-
-    - Otherwise, the DWARF expression is ill-formed
-
-    <i>Many compilers store a single variable in sets of registers or store a
-    variable partially in memory and partially in registers. `DW_OP_piece`
-    provides a way of describing where a part of a variable is located.</i>
-
-    <i>The evaluation rules for the `DW_OP_piece` operation allow it to be
-    compatible with the DWARF Version 5 definition.</i>
-
-    > NOTE: Since these extensions allow location descriptions to be entries on
-    > the stack, a simpler operation to create composite location descriptions
-    > could be defined. For example, just one operation that specifies how many
-    > parts, and pops pairs of stack entries for the part size and location
-    > description. Not only would this be a simpler operation and avoid the
-    > complexities of incomplete composite location descriptions, but it may
-    > also have a smaller encoding in practice. However, the desire for
-    > compatibility with DWARF Version 5 is likely a stronger consideration.
-
-2.  `DW_OP_bit_piece`
-
-    `DW_OP_bit_piece` has two operands. The first is an unsigned LEB128 integer
-    that represents the part bit size S. The second is an unsigned LEB128
-    integer that represents a bit displacement B.
-
-    The action is the same as for `DW_OP_piece`, except that any part created
-    has the bit size S, and the location description PL of any created part is
-    updated by a bit offset B.
-
-    <i>`DW_OP_bit_piece` is used instead of `DW_OP_piece` when the piece to be
-    assembled is not byte-sized or is not at the start of the part location
-    description.</i>
-
-#### A.2.5.5 DWARF Location List Expressions
-
-> NOTE: This section replaces DWARF Version 5 section 2.6.2.
-
-<i>To meet the needs of recent computer architectures and optimization
-techniques, debugging information must be able to describe the location of an
-object whose location changes over the object's lifetime, and may reside at
-multiple locations during parts of an object's lifetime. Location list
-expressions are used in place of operation expressions whenever the object whose
-location is being described has these requirements.</i>
-
-A location list expression consists of a series of location list entries. Each
-location list entry is one of the following kinds:
-
-1.  <i>Bounded location description</i>
-
-    This kind of location list entry provides an operation expression that
-    evaluates to the location description of an object that is valid over a
-    lifetime bounded by a starting and ending address. The starting address is
-    the lowest address of the address range over which the location is valid.
-    The ending address is the address of the first location past the highest
-    address of the address range.
-
-    The location list entry matches when the current program location is within
-    the given range.
-
-    There are several kinds of bounded location description entries which differ
-    in the way that they specify the starting and ending addresses.
-
-2.  <i>Default location description</i>
-
-    This kind of location list entry provides an operation expression that
-    evaluates to the location description of an object that is valid when no
-    bounded location description entry applies.
-
-    The location list entry matches when the current program location is not
-    within the range of any bounded location description entry.
-
-3.  <i>Base address</i>
-
-    This kind of location list entry provides an address to be used as the base
-    address for beginning and ending address offsets given in certain kinds of
-    bounded location description entries. The applicable base address of a
-    bounded location description entry is the address specified by the closest
-    preceding base address entry in the same location list. If there is no
-    preceding base address entry, then the applicable base address defaults to
-    the base address of the compilation unit (see DWARF Version 5 section
-    3.1.1).
-
-    In the case of a compilation unit where all of the machine code is contained
-    in a single contiguous section, no base address entry is needed.
-
-4.  <i>End-of-list</i>
-
-    This kind of location list entry marks the end of the location list
-    expression.
-
-The address ranges defined by the bounded location description entries of a
-location list expression may overlap. When they do, they describe a situation in
-which an object exists simultaneously in more than one place.
-
-If all of the address ranges in a given location list expression do not
-collectively cover the entire range over which the object in question is
-defined, and there is no following default location description entry, it is
-assumed that the object is not available for the portion of the range that is
-not covered.
-
-The result of the evaluation of a DWARF location list expression is:
-
-- If the current program location is not specified, then it is an evaluation
-  error.
-
-  > NOTE: If the location list only has a single default entry, should that be
-  > considered a match if there is no program location? If there are non-default
-  > entries then it seems it has to be an evaluation error when there is no
-  > program location as that indicates the location depends on the program
-  > location which is not known.
-
-- If there are no matching location list entries, then the result is a location
-  description that comprises one undefined location description.
-- Otherwise, the operation expression E of each matching location list entry is
-  evaluated with the current context, except that the result kind is a location
-  description, the object is unspecified, and the initial stack is empty. The
-  location list entry result is the location description returned by the
-  evaluation of E.
-
-  The result is a location description that is comprised of the union of the
-  single location descriptions of the location description result of each
-  matching location list entry.
-
-A location list expression can only be used as the value of a debugger
-information entry attribute that is encoded using class `loclist` or
-`loclistsptr` (see [7.5.5 Classes and Forms](#classes-and-forms)). The value of
-the attribute provides an index into a separate object file section called
-`.debug_loclists` or `.debug_loclists.dwo` (for split DWARF object files) that
-contains the location list entries.
-
-A `DW_OP_call*` and `DW_OP_implicit_pointer` operation can be used to specify a
-debugger information entry attribute that has a location list expression.
-Several debugger information entry attributes allow DWARF expressions that are
-evaluated with an initial stack that includes a location description that may
-originate from the evaluation of a location list expression.
-
-<i>This location list representation, the `loclist` and `loclistsptr` class, and
-the related `DW_AT_loclists_base` attribute are new in DWARF Version 5. Together
-they eliminate most, or all of the code object relocations previously needed for
-location list expressions.</i>
-
-> NOTE: The rest of this section is the same as DWARF Version 5 section 2.6.2.
-
-## A.3 Program Scope Entries
-
-> NOTE: This section provides changes to existing debugger information entry
-> attributes. These would be incorporated into the corresponding DWARF Version 5
-> chapter 3 sections.
-
-### A.3.3 Subroutine and Entry Point Entries
-
-#### A.3.3.5 Low-Level Information
-
-1.  A `DW_TAG_subprogram`, `DW_TAG_inlined_subroutine`, or `DW_TAG_entry_point`
-    debugger information entry may have a `DW_AT_return_addr` attribute, whose
-    value is a DWARF expression E.
-
-    The result of the attribute is obtained by evaluating E with a context that
-    has a result kind of a location description, an unspecified object, the
-    compilation unit that contains E, an empty initial stack, and other context
-    elements corresponding to the source language thread of execution upon which
-    the user is focused, if any. The result of the evaluation is the location
-    description L of the place where the return address for the current call
-    frame's subprogram or entry point is stored.
-
-    The DWARF is ill-formed if L is not comprised of one memory location
-    description for one of the target architecture specific address spaces.
-
-    > NOTE: It is unclear why `DW_TAG_inlined_subroutine` has a
-    > `DW_AT_return_addr` attribute but not a `DW_AT_frame_base` or
-    > `DW_AT_static_link` attribute. Seems it would either have all of them or
-    > none. Since inlined subprograms do not have a call frame it seems they
-    > would have none of these attributes.
-
-2.  A `DW_TAG_subprogram` or `DW_TAG_entry_point` debugger information entry may
-    have a `DW_AT_frame_base` attribute, whose value is a DWARF expression E.
-
-    The result of the attribute is obtained by evaluating E with a context that
-    has a result kind of a location description, an unspecified object, the
-    compilation unit that contains E, an empty initial stack, and other context
-    elements corresponding to the source language thread of execution upon which
-    the user is focused, if any.
-
-    The DWARF is ill-formed if E contains an `DW_OP_fbreg` operation, or the
-    resulting location description L is not comprised of one single location
-    description SL.
-
-    If SL is a register location description for register R, then L is replaced
-    with the result of evaluating a `DW_OP_bregx R, 0` operation. This computes
-    the frame base memory location description in the target architecture
-    default address space.
-
-    <i>This allows the more compact `DW_OP_reg*` to be used instead of
-    `DW_OP_breg* 0`.</i>
-
-    > NOTE: This rule could be removed and require the producer to create the
-    > required location description directly using `DW_OP_call_frame_cfa` or
-    > `DW_OP_breg*`. This would also then allow a target to implement the call
-    > frames within a large register.
-
-    Otherwise, the DWARF is ill-formed if SL is not a memory location
-    description in any of the target architecture specific address spaces.
-
-    The resulting L is the <i>frame base</i> for the subprogram or entry point.
-
-    <i>Typically, E will use the `DW_OP_call_frame_cfa` operation or be a stack
-    pointer register plus or minus some offset.</i>
-
-3.  If a `DW_TAG_subprogram` or `DW_TAG_entry_point` debugger information entry
-    is lexically nested, it may have a `DW_AT_static_link` attribute, whose
-    value is a DWARF expression E.
-
-    The result of the attribute is obtained by evaluating E with a context that
-    has a result kind of a location description, an unspecified object, the
-    compilation unit that contains E, an empty initial stack, and other context
-    elements corresponding to the source language thread of execution upon which
-    the user is focused, if any. The result of the evaluation is the location
-    description L of the <i>canonical frame address</i> (see [6.4 Call Frame
-    Information](#call-frame-information)) of the relevant call frame of the
-    subprogram instance that immediately lexically encloses the current call
-    frame's subprogram or entry point.
-
-    The DWARF is ill-formed if L is is not comprised of one memory location
-    description for one of the target architecture specific address spaces.
-
-### A.3.4 Call Site Entries and Parameters
-
-#### A.3.4.2 Call Site Parameters
-
-1.  A `DW_TAG_call_site_parameter` debugger information entry may have a
-    `DW_AT_call_value` attribute, whose value is a DWARF operation expression
-    E<sub>1</sub>.
-
-    The result of the `DW_AT_call_value` attribute is obtained by evaluating
-    E<sub>1</sub> with a context that has a result kind of a value, an unspecified
-    object, the compilation unit that contains E, an empty initial stack, and other
-    context elements corresponding to the source language thread of execution upon
-    which the user is focused, if any. The resulting value V<sub>1</sub> is the
-    value of the parameter at the time of the call made by the call site.
-
-    For parameters passed by reference, where the code passes a pointer to a
-    location which contains the parameter, or for reference type parameters, the
-    `DW_TAG_call_site_parameter` debugger information entry may also have a
-    `DW_AT_call_data_location` attribute whose value is a DWARF operation expression
-    E<sub>2</sub>, and a `DW_AT_call_data_value` attribute whose value is a DWARF
-    operation expression E<sub>3</sub>.
-
-    The value of the `DW_AT_call_data_location` attribute is obtained by evaluating
-    E<sub>2</sub> with a context that has a result kind of a location description,
-    an unspecified object, the compilation unit that contains E, an empty initial
-    stack, and other context elements corresponding to the source language thread of
-    execution upon which the user is focused, if any. The resulting location
-    description L<sub>2</sub> is the location where the referenced parameter lives
-    during the call made by the call site. If E<sub>2</sub> would just be a
-    `DW_OP_push_object_address`, then the `DW_AT_call_data_location` attribute may
-    be omitted.
-
-    > NOTE: The DWARF Version 5 implies that `DW_OP_push_object_address` may be
-    > used but does not state what object must be specified in the context.
-    > Either `DW_OP_push_object_address` cannot be used, or the object to be
-    > passed in the context must be defined.
-
-    The value of the `DW_AT_call_data_value` attribute is obtained by evaluating
-    E<sub>3</sub> with a context that has a result kind of a value, an unspecified
-    object, the compilation unit that contains E, an empty initial stack, and other
-    context elements corresponding to the source language thread of execution upon
-    which the user is focused, if any. The resulting value V<sub>3</sub> is the
-    value in L<sub>2</sub> at the time of the call made by the call site.
-
-    The result of these attributes is undefined if the current call frame is not for
-    the subprogram containing the `DW_TAG_call_site_parameter` debugger information
-    entry or the current program location is not for the call site containing the
-    `DW_TAG_call_site_parameter` debugger information entry in the current call
-    frame.
-
-    <i>The consumer may have to virtually unwind to the call site (see [6.4 Call
-    Frame Information](#call-frame-information)) in order to evaluate these
-    attributes. This will ensure the source language thread of execution upon which
-    the user is focused corresponds to the call site needed to evaluate the
-    expression.</i>
-
-    If it is not possible to avoid the expressions of these attributes from
-    accessing registers or memory locations that might be clobbered by the
-    subprogram being called by the call site, then the associated attribute should
-    not be provided.
-
-    <i>The reason for the restriction is that the parameter may need to be accessed
-    during the execution of the callee. The consumer may virtually unwind from the
-    called subprogram back to the caller and then evaluate the attribute
-    expressions. The call frame information (see [6.4 Call Frame
-    Information](#call-frame-information)) will not be able to restore registers
-    that have been clobbered, and clobbered memory will no longer have the value at
-    the time of the call.</i>
-
-### A.3.5 Lexical Block Entries
-
-> NOTE: This section is the same as DWARF Version 5 section 3.5.
-
-## A.4 Data Object and Object List Entries
-
-> NOTE: This section provides changes to existing debugger information entry
-> attributes. These would be incorporated into the corresponding DWARF Version 5
-> chapter 4 sections.
-
-### A.4.1 Data Object Entries
-
-1.  Any debugging information entry describing a data object (which includes
-    variables and parameters) or common blocks may have a `DW_AT_location`
-    attribute, whose value is a DWARF expression E.
-
-    The result of the attribute is obtained by evaluating E with a context that
-    has a result kind of a location description, an unspecified object, the
-    compilation unit that contains E, an empty initial stack, and other context
-    elements corresponding to the source language thread of execution upon which
-    the user is focused, if any. The result of the evaluation is the location
-    description of the base of the data object.
-
-    See [2.5.4.2 Control Flow Operations](#control-flow-operations) for special
-    evaluation rules used by the `DW_OP_call*` operations.
-
-    > NOTE: Delete the description of how the `DW_OP_call*` operations evaluate
-    > a `DW_AT_location` attribute as that is now described in the operations.
-
-    > NOTE: See the discussion about the `DW_AT_location` attribute in the
-    > `DW_OP_call*` operation. Having each attribute only have a single purpose
-    > and single execution semantics seems desirable. It makes it easier for the
-    > consumer that no longer have to track the context. It makes it easier for
-    > the producer as it can rely on a single semantics for each attribute.
-    >
-    > For that reason, limiting the `DW_AT_location` attribute to only
-    > supporting evaluating the location description of an object, and using a
-    > different attribute and encoding class for the evaluation of DWARF
-    > expression <i>procedures</i> on the same operation expression stack seems
-    > desirable.
-
-2.  `DW_AT_const_value`
-
-    > NOTE: Could deprecate using the `DW_AT_const_value` attribute for
-    > `DW_TAG_variable` or `DW_TAG_formal_parameter` debugger information
-    > entries that have been optimized to a constant. Instead, `DW_AT_location`
-    > could be used with a DWARF expression that produces an implicit location
-    > description now that any location description can be used within a DWARF
-    > expression. This allows the `DW_OP_call*` operations to be used to push
-    > the location description of any variable regardless of how it is
-    > optimized.
-
-## A.5 Type Entries
-
-> NOTE: This section provides changes to existing debugger information entry
-> attributes. These would be incorporated into the corresponding DWARF Version 5
-> chapter 5 sections.
-
-### A.5.7 Structure, Union, Class and Interface Type Entries
-
-#### A.5.7.3 Derived or Extended Structures, Classes and Interfaces
-
-1.  For a `DW_AT_data_member_location` attribute there are two cases:
-
-    1.  If the attribute is an integer constant B, it provides the offset in
-        bytes from the beginning of the containing entity.
-
-        The result of the attribute is obtained by updating the bit offset of
-        the location description of the beginning of the containing entity by B
-        scaled by 8 (the byte size). The result is the location description of
-        the base of the member entry.
-
-        <i>If the beginning of the containing entity is not byte aligned, then
-        the beginning of the member entry has the same bit displacement within a
-        byte.</i>
-
-    2.  Otherwise, the attribute must be a DWARF expression E which is evaluated
-        with a context that has a result kind of a location description, an
-        unspecified object, the compilation unit that contains E, an initial
-        stack comprising the location description of the beginning of the
-        containing entity, and other context elements corresponding to the
-        source language thread of execution upon which the user is focused, if
-        any. The result of the evaluation is the location description of the
-        base of the member entry.
-
-    > NOTE: The beginning of the containing entity can now be any location
-    > description, including those with more than one single location
-    > description, and those with single location descriptions that are of any
-    > kind and have any bit offset.
-
-#### A.5.7.8 Member Function Entries
-
-1.  An entry for a virtual function also has a `DW_AT_vtable_elem_location`
-    attribute whose value is a DWARF expression E.
-
-    The result of the attribute is obtained by evaluating E with a context that
-    has a result kind of a location description, an unspecified object, the
-    compilation unit that contains E, an initial stack comprising the location
-    description of the object of the enclosing type, and other context elements
-    corresponding to the source language thread of execution upon which the user
-    is focused, if any. The result of the evaluation is the location description
-    of the slot for the function within the virtual function table for the
-    enclosing class.
-
-### A.5.14 Pointer to Member Type Entries
-
-1.  The `DW_TAG_ptr_to_member_type` debugging information entry has a
-    `DW_AT_use_location` attribute whose value is a DWARF expression E. It is used
-    to compute the location description of the member of the class to which the
-    pointer to member entry points.
-
-    <i>The method used to find the location description of a given member of a
-    class, structure, or union is common to any instance of that class, structure,
-    or union and to any instance of the pointer to member type. The method is thus
-    associated with the pointer to member type, rather than with each object that
-    has a pointer to member type.</i>
-
-    The `DW_AT_use_location` DWARF expression is used in conjunction with the
-    location description for a particular object of the given pointer to member type
-    and for a particular structure or class instance.
-
-    The result of the attribute is obtained by evaluating E with a context that has
-    a result kind of a location description, an unspecified object, the compilation
-    unit that contains E, an initial stack comprising two entries, and other context
-    elements corresponding to the source language thread of execution upon which the
-    user is focused, if any. The first stack entry is the value of the pointer to
-    member object itself. The second stack entry is the location description of the
-    base of the entire class, structure, or union instance containing the member
-    whose location is being calculated. The result of the evaluation is the location
-    description of the member of the class to which the pointer to member entry
-    points.
-
-### A.5.16 Dynamic Type Entries
-
-1.  The `DW_AT_data_location` attribute may be used with any type that provides one
-    or more levels of hidden indirection and/or run-time parameters in its
-    representation. Its value is a DWARF operation expression E which computes the
-    location description of the data for an object. When this attribute is omitted,
-    the location description of the data is the same as the location description of
-    the object.
-
-    The result of the attribute is obtained by evaluating E with a context that has
-    a result kind of a location description, an object that is the location
-    description of the data descriptor, the compilation unit that contains E, an
-    empty initial stack, and other context elements corresponding to the source
-    language thread of execution upon which the user is focused, if any. The result
-    of the evaluation is the location description of the base of the member entry.
-
-    <i>E will typically involve an operation expression that begins with a
-    `DW_OP_push_object_address` operation which loads the location description
-    of the object which can then serve as a descriptor in subsequent
-    calculation.</i>
-
-    > NOTE: Since `DW_AT_data_member_location`, `DW_AT_use_location`, and
-    > `DW_AT_vtable_elem_location` allow both operation expressions and location
-    > list expressions, why does `DW_AT_data_location` not allow both? In all cases
-    > they apply to data objects so less likely that optimization would cause
-    > different operation expressions for different program location ranges. But if
-    > supporting for some then should be for all.
-    >
-    > It seems odd this attribute is not the same as `DW_AT_data_member_location` in
-    > having an initial stack with the location description of the object since the
-    > expression has to need it.
-
-## A.6 Other Debugging Information
-
-> NOTE: This section provides changes to existing debugger information entry
-> attributes. These would be incorporated into the corresponding DWARF Version 5
-> chapter 6 sections.
-
-### A.6.2 Line Number Information
-
-> NOTE: This section is the same as DWARF Version 5 section 6.2.
-
-### A.6.4 Call Frame Information
-
-> NOTE: This section provides changes to DWARF Version 5 section 6.4. Register
-> unwind DWARF expressions are generalized to allow any location description,
-> including those with composite and implicit location descriptions.
-
-#### A.6.4.1 Structure of Call Frame Information
-
-The register rules are:
-
-1.  <i>undefined</i>
-
-    A register that has this rule has no recoverable value in the previous
-    frame. The previous value of this register is the undefined location
-    description (see [2.5.4.4.2 Undefined Location Description
-    Operations](#undefined-location-description-operations)).
-
-    <i>By convention, the register is not preserved by a callee.</i>
-
-2.  <i>same value</i>
-
-    This register has not been modified from the previous caller frame.
-
-    If the current frame is the top frame, then the previous value of this
-    register is the location description L that specifies one register location
-    description SL. SL specifies the register location storage that corresponds
-    to the register with a bit offset of 0 for the current thread.
-
-    If the current frame is not the top frame, then the previous value of this
-    register is the location description obtained using the call frame
-    information for the callee frame and callee program location invoked by the
-    current caller frame for the same register.
-
-    <i>By convention, the register is preserved by the callee, but the callee
-    has not modified it.</i>
-
-3.  <i>offset(N)</i>
-
-    N is a signed byte offset. The previous value of this register is saved at
-    the location description L. Where L is the location description of the
-    current CFA (see [2.5.4 DWARF Operation
-    Expressions](#dwarf-operation-expressions)) updated with the bit offset N
-    scaled by 8 (the byte size).
-
-4.  <i>val_offset(N)</i>
-
-    N is a signed byte offset. The previous value of this register is the memory
-    byte address of the location description L. Where L is the location
-    description of the current CFA (see [2.5.4 DWARF Operation
-    Expressions](#dwarf-operation-expressions)) updated with the bit offset N
-    scaled by 8 (the byte size).
-
-    The DWARF is ill-formed if the CFA location description is not a memory byte
-    address location description, or if the register size does not match the
-    size of an address in the target architecture default address space.
-
-    <i>Since the CFA location description is required to be a memory byte
-    address location description, the value of val_offset(N) will also be a
-    memory byte address location description since it is offsetting the CFA
-    location description by N bytes. Furthermore, the value of val_offset(N)
-    will be a memory byte address in the target architecture default address
-    space.</i>
-
-    > NOTE: Should DWARF allow the address size to be a different size to the
-    > size of the register? Requiring them to be the same bit size avoids any
-    > issue of conversion as the bit contents of the register is simply
-    > interpreted as a value of the address.
-    >
-    > GDB has a per register hook that allows a target specific conversion on a
-    > register by register basis. It defaults to truncation of bigger registers,
-    > and to actually reading bytes from the next register (or reads out of
-    > bounds for the last register) for smaller registers. There are no GDB
-    > tests that read a register out of bounds (except an illegal hand written
-    > assembly test).
-
-5.  <i>register(R)</i>
-
-    This register has been stored in another register numbered R.
-
-    The previous value of this register is the location description obtained
-    using the call frame information for the current frame and current program
-    location for register R.
-
-    The DWARF is ill-formed if the size of this register does not match the size
-    of register R or if there is a cyclic dependency in the call frame
-    information.
-
-    > NOTE: Should this also allow R to be larger than this register? If so is
-    > the value stored in the low order bits and it is undefined what is stored
-    > in the extra upper bits?
-
-6.  <i>expression(E)</i>
-
-    The previous value of this register is located at the location description
-    produced by evaluating the DWARF operation expression E (see [2.5.4 DWARF
-    Operation Expressions](#dwarf-operation-expressions)).
-
-    E is evaluated with the current context, except the result kind is a
-    location description, the compilation unit is unspecified, the object is
-    unspecified, and an initial stack comprising the location description of the
-    current CFA (see [2.5.4 DWARF Operation
-    Expressions](#dwarf-operation-expressions)).
-
-7.  <i>val_expression(E)</i>
-
-    The previous value of this register is the value produced by evaluating the
-    DWARF operation expression E (see [2.5.4 DWARF Operation
-    Expressions](#dwarf-operation-expressions)).
-
-    E is evaluated with the current context, except the result kind is a value,
-    the compilation unit is unspecified, the object is unspecified, and an
-    initial stack comprising the location description of the current CFA (see
-    [2.5.4 DWARF Operation Expressions](#dwarf-operation-expressions)).
-
-    The DWARF is ill-formed if the resulting value type size does not match the
-    register size.
-
-    > NOTE: This has limited usefulness as the DWARF expression E can only
-    > produce values up to the size of the generic type. This is due to not
-    > allowing any operations that specify a type in a CFI operation expression.
-    > This makes it unusable for registers that are larger than the generic
-    > type. However, <i>expression(E)</i> can be used to create an implicit
-    > location description of any size.
-
-8.  <i>architectural</i>
-
-    The rule is defined externally to this specification by the augmenter.
-
-A Common Information Entry (CIE) holds information that is shared among many
-Frame Description Entries (FDE). There is at least one CIE in every non-empty
-`.debug_frame` section. A CIE contains the following fields, in order:
-
-1.  `length` (initial length)
-
-    A constant that gives the number of bytes of the CIE structure, not
-    including the length field itself. The size of the length field plus the
-    value of length must be an integral multiple of the address size specified
-    in the `address_size` field.
-
-2.  `CIE_id` (4 or 8 bytes, see [7.4 32-Bit and 64-Bit DWARF
-    Formats](#32-bit-and-64-bit-dwarf-formats))
-
-    A constant that is used to distinguish CIEs from FDEs.
-
-    In the 32-bit DWARF format, the value of the CIE id in the CIE header is
-    0xffffffff; in the 64-bit DWARF format, the value is 0xffffffffffffffff.
-
-3.  `version` (ubyte)
-
-    A version number. This number is specific to the call frame information and
-    is independent of the DWARF version number.
-
-    The value of the CIE version number is 4.
-
-    > NOTE: Would this be increased to 5 to reflect the changes in these
-    > extensions?
-
-4.  `augmentation` (sequence of UTF-8 characters)
-
-    A null-terminated UTF-8 string that identifies the augmentation to this CIE
-    or to the FDEs that use it. If a reader encounters an augmentation string
-    that is unexpected, then only the following fields can be read:
-
-    - CIE: length, CIE_id, version, augmentation
-    - FDE: length, CIE_pointer, initial_location, address_range
-
-    If there is no augmentation, this value is a zero byte.
-
-    <i>The augmentation string allows users to indicate that there is additional
-    vendor and target architecture specific information in the CIE or FDE which
-    is needed to virtually unwind a stack frame. For example, this might be
-    information about dynamically allocated data which needs to be freed on exit
-    from the routine.</i>
-
-    <i>Because the `.debug_frame` section is useful independently of any
-    `.debug_info` section, the augmentation string always uses UTF-8
-    encoding.</i>
-
-5.  `address_size` (ubyte)
-
-    The size of a target address in this CIE and any FDEs that use it, in bytes.
-    If a compilation unit exists for this frame, its address size must match the
-    address size here.
-
-6.  `segment_selector_size` (ubyte)
-
-    The size of a segment selector in this CIE and any FDEs that use it, in
-    bytes.
-
-7.  `code_alignment_factor` (unsigned LEB128)
-
-    A constant that is factored out of all advance location instructions (see
-    [6.4.2.1 Row Creation Instructions](#row-creation-instructions)). The
-    resulting value is `(operand * code_alignment_factor)`.
-
-8.  `data_alignment_factor` (signed LEB128)
-
-    A constant that is factored out of certain offset instructions (see [6.4.2.2
-    CFA Definition Instructions](#cfa-definition-instructions) and [6.4.2.3
-    Register Rule Instructions](#register-rule-instructions)). The
-    resulting value is `(operand * data_alignment_factor)`.
-
-9.  `return_address_register` (unsigned LEB128)
-
-    An unsigned LEB128 constant that indicates which column in the rule table
-    represents the return address of the subprogram. Note that this column might
-    not correspond to an actual machine register.
-
-    The value of the return address register is used to determine the program
-    location of the caller frame. The program location of the top frame is the
-    target architecture program counter value of the current thread.
-
-10. `initial_instructions` (array of ubyte)
-
-    A sequence of rules that are interpreted to create the initial setting of
-    each column in the table.
-
-    The default rule for all columns before interpretation of the initial
-    instructions is the undefined rule. However, an ABI authoring body or a
-    compilation system authoring body may specify an alternate default value for
-    any or all columns.
-
-11. `padding` (array of ubyte)
-
-    Enough `DW_CFA_nop` instructions to make the size of this entry match the
-    length value above.
-
-An FDE contains the following fields, in order:
-
-1.  `length` (initial length)
-
-    A constant that gives the number of bytes of the header and instruction
-    stream for this subprogram, not including the length field itself. The size
-    of the length field plus the value of length must be an integral multiple of
-    the address size.
-
-2.  `CIE_pointer` (4 or 8 bytes, see [7.4 32-Bit and 64-Bit DWARF
-    Formats](#32-bit-and-64-bit-dwarf-formats))
-
-    A constant offset into the `.debug_frame` section that denotes the CIE that
-    is associated with this FDE.
-
-3.  `initial_location` (segment selector and target address)
-
-    The address of the first location associated with this table entry. If the
-    segment_selector_size field of this FDE's CIE is non-zero, the initial
-    location is preceded by a segment selector of the given length.
-
-4.  `address_range` (target address)
-
-    The number of bytes of program instructions described by this entry.
-
-5.  `instructions` (array of ubyte)
-
-    A sequence of table defining instructions that are described in [6.4.2 Call
-    Frame Instructions](#call-frame-instructions).
-
-6.  `padding` (array of ubyte)
-
-    Enough `DW_CFA_nop` instructions to make the size of this entry match the
-    length value above.
-
-#### A.6.4.2 Call Frame Instructions
-
-Some call frame instructions have operands that are encoded as DWARF operation
-expressions E (see [2.5.4 DWARF Operation
-Expressions](#dwarf-operation-expressions)). The DWARF operations that can be
-used in E have the following restrictions:
-
-- `DW_OP_addrx`, `DW_OP_call2`, `DW_OP_call4`, `DW_OP_call_ref`,
-  `DW_OP_const_type`, `DW_OP_constx`, `DW_OP_convert`, `DW_OP_deref_type`,
-  `DW_OP_fbreg`, `DW_OP_implicit_pointer`, `DW_OP_regval_type`,
-  `DW_OP_reinterpret`, and `DW_OP_xderef_type` operations are not allowed
-  because the call frame information must not depend on other debug sections.
-- `DW_OP_push_object_address` is not allowed because there is no object context
-  to provide a value to push.
-- `DW_OP_call_frame_cfa` and `DW_OP_entry_value` are not allowed because their
-  use would be circular.
-
-<i>Call frame instructions to which these restrictions apply include
-`DW_CFA_def_cfa_expression`, `DW_CFA_expression`, and
-`DW_CFA_val_expression`.</i>
-
-##### A.6.4.2.1 Row Creation Instructions
-
-> NOTE: These instructions are the same as in DWARF Version 5 section 6.4.2.1.
-
-##### A.6.4.2.2 CFA Definition Instructions
-
-1.  `DW_CFA_def_cfa`
-
-    The `DW_CFA_def_cfa` instruction takes two unsigned LEB128 operands
-    representing a register number R and a (non-factored) byte displacement B.
-    The required action is to define the current CFA rule to be the result of
-    evaluating the DWARF operation expression `DW_OP_bregx R, B` as a location
-    description.
-
-2.  `DW_CFA_def_cfa_sf`
-
-    The `DW_CFA_def_cfa_sf` instruction takes two operands: an unsigned LEB128
-    value representing a register number R and a signed LEB128 factored byte
-    displacement B. The required action is to define the current CFA rule to be
-    the result of evaluating the DWARF operation expression `DW_OP_bregx R, B *
-    data_alignment_factor` as a location description.
-
-    <i>The action is the same as `DW_CFA_def_cfa`, except that the second
-    operand is signed and factored.</i>
-
-3.  `DW_CFA_def_cfa_register`
-
-    The `DW_CFA_def_cfa_register` instruction takes a single unsigned LEB128
-    operand representing a register number R. The required action is to define
-    the current CFA rule to be the result of evaluating the DWARF operation
-    expression `DW_OP_bregx R, B` as a location description. B is the old CFA
-    byte displacement.
-
-    If the subprogram has no current CFA rule, or the rule was defined by a
-    `DW_CFA_def_cfa_expression` instruction, then the DWARF is ill-formed.
-
-4.  `DW_CFA_def_cfa_offset`
-
-    The `DW_CFA_def_cfa_offset` instruction takes a single unsigned LEB128
-    operand representing a (non-factored) byte displacement B. The required
-    action is to define the current CFA rule to be the result of evaluating the
-    DWARF operation expression `DW_OP_bregx R, B` as a location description. R
-    is the old CFA register number.
-
-    If the subprogram has no current CFA rule, or the rule was defined by a
-    `DW_CFA_def_cfa_expression` instruction, then the DWARF is ill-formed.
-
-5.  `DW_CFA_def_cfa_offset_sf`
-
-    The `DW_CFA_def_cfa_offset_sf` instruction takes a signed LEB128 operand
-    representing a factored byte displacement B. The required action is to
-    define the current CFA rule to be the result of evaluating the DWARF
-    operation expression `DW_OP_bregx R, B * data_alignment_factor` as a
-    location description. R is the old CFA register number.
-
-    If the subprogram has no current CFA rule, or the rule was defined by a
-    `DW_CFA_def_cfa_expression` instruction, then the DWARF is ill-formed.
-
-    <i>The action is the same as `DW_CFA_def_cfa_offset`, except that the
-    operand is signed and factored.</i>
-
-6.  `DW_CFA_def_cfa_expression`
-
-    The `DW_CFA_def_cfa_expression` instruction takes a single operand encoded
-    as a `DW_FORM_exprloc` value representing a DWARF operation expression E.
-    The required action is to define the current CFA rule to be the result of
-    evaluating E with the current context, except the result kind is a location
-    description, the compilation unit is unspecified, the object is unspecified,
-    and an empty initial stack.
-
-    <i>See [6.4.2 Call Frame Instructions](#call-frame-instructions) regarding
-    restrictions on the DWARF expression operations that can be used in E.</i>
-
-    The DWARF is ill-formed if the result of evaluating E is not a memory byte
-    address location description.
-
-##### A.6.4.2.3 Register Rule Instructions
-
-1.  `DW_CFA_undefined`
-
-    The `DW_CFA_undefined` instruction takes a single unsigned LEB128 operand
-    that represents a register number R. The required action is to set the rule
-    for the register specified by R to `undefined`.
-
-2.  `DW_CFA_same_value`
-
-    The `DW_CFA_same_value` instruction takes a single unsigned LEB128 operand
-    that represents a register number R. The required action is to set the rule
-    for the register specified by R to `same value`.
-
-3.  `DW_CFA_offset`
-
-    The `DW_CFA_offset` instruction takes two operands: a register number R
-    (encoded with the opcode) and an unsigned LEB128 constant representing a
-    factored displacement B. The required action is to change the rule for the
-    register specified by R to be an <i>offset(B * data_alignment_factor)</i>
-    rule.
-
-    > NOTE: Seems this should be named `DW_CFA_offset_uf` since the offset is
-    > unsigned factored.
-
-4.  `DW_CFA_offset_extended`
-
-    The `DW_CFA_offset_extended` instruction takes two unsigned LEB128 operands
-    representing a register number R and a factored displacement B. This
-    instruction is identical to `DW_CFA_offset`, except for the encoding and
-    size of the register operand.
-
-    > NOTE: Seems this should be named `DW_CFA_offset_extended_uf` since the
-    > displacement is unsigned factored.
-
-5.  `DW_CFA_offset_extended_sf`
-
-    The `DW_CFA_offset_extended_sf` instruction takes two operands: an unsigned
-    LEB128 value representing a register number R and a signed LEB128 factored
-    displacement B. This instruction is identical to `DW_CFA_offset_extended`,
-    except that B is signed.
-
-6.  `DW_CFA_val_offset`
-
-    The `DW_CFA_val_offset` instruction takes two unsigned LEB128 operands
-    representing a register number R and a factored displacement B. The required
-    action is to change the rule for the register indicated by R to be a
-    <i>val_offset(B * data_alignment_factor)</i> rule.
-
-    > NOTE: Seems this should be named `DW_CFA_val_offset_uf` since the
-    displacement is unsigned factored.
-
-7.  `DW_CFA_val_offset_sf`
-
-    The `DW_CFA_val_offset_sf` instruction takes two operands: an unsigned
-    LEB128 value representing a register number R and a signed LEB128 factored
-    displacement B. This instruction is identical to `DW_CFA_val_offset`, except
-    that B is signed.
-
-8.  `DW_CFA_register`
-
-    The `DW_CFA_register` instruction takes two unsigned LEB128 operands
-    representing register numbers R1 and R2 respectively. The required action is
-    to set the rule for the register specified by R1 to be a <i>register(R2)</i>
-    rule.
-
-9.  `DW_CFA_expression`
-
-    The `DW_CFA_expression` instruction takes two operands: an unsigned LEB128
-    value representing a register number R, and a `DW_FORM_block` value
-    representing a DWARF operation expression E. The required action is to
-    change the rule for the register specified by R to be an
-    <i>expression(E)</i> rule.
-
-    <i>That is, E computes the location description where the register value can
-    be retrieved.</i>
-
-    <i>See [6.4.2 Call Frame Instructions](#call-frame-instructions) regarding
-    restrictions on the DWARF expression operations that can be used in E.</i>
-
-10. `DW_CFA_val_expression`
-
-    The `DW_CFA_val_expression` instruction takes two operands: an unsigned
-    LEB128 value representing a register number R, and a `DW_FORM_block` value
-    representing a DWARF operation expression E. The required action is to
-    change the rule for the register specified by R to be a
-    <i>val_expression(E)</i> rule.
-
-    <i>That is, E computes the value of register R.</i>
-
-    <i>See [6.4.2 Call Frame Instructions](#call-frame-instructions) regarding
-    restrictions on the DWARF expression operations that can be used in E.</i>
-
-    If the result of evaluating E is not a value with a base type size that
-    matches the register size, then the DWARF is ill-formed.
-
-11. `DW_CFA_restore`
-
-    The `DW_CFA_restore` instruction takes a single operand (encoded with the
-    opcode) that represents a register number R. The required action is to
-    change the rule for the register specified by R to the rule assigned it by
-    the `initial_instructions` in the CIE.
-
-12. `DW_CFA_restore_extended`
-
-    The `DW_CFA_restore_extended` instruction takes a single unsigned LEB128
-    operand that represents a register number R. This instruction is identical
-    to `DW_CFA_restore`, except for the encoding and size of the register
-    operand.
-
-##### A.6.4.2.4 Row State Instructions
-
-> NOTE: These instructions are the same as in DWARF Version 5 section 6.4.2.4.
-
-##### A.6.4.2.5 Padding Instruction
-
-> NOTE: These instructions are the same as in DWARF Version 5 section 6.4.2.5.
-
-#### A.6.4.3 Call Frame Instruction Usage
-
-> NOTE: The same as in DWARF Version 5 section 6.4.3.
-
-#### A.6.4.4 Call Frame Calling Address
-
-> NOTE: The same as in DWARF Version 5 section 6.4.4.
-
-## A.7 Data Representation
-
-> NOTE: This section provides changes to existing debugger information entry
-> attributes. These would be incorporated into the corresponding DWARF Version 5
-> chapter 7 sections.
-
-### A.7.4 32-Bit and 64-Bit DWARF Formats
-
-> NOTE: This augments DWARF Version 5 section 7.4 list item 3's table.
-
-    Form                     Role
-    ------------------------ --------------------------------------
-    DW_OP_implicit_pointer   offset in `.debug_info`
-
-### A.7.5 Format of Debugging Information
-
-#### A.7.5.5 Classes and Forms
-
-> NOTE: The same as in DWARF Version 5 section 7.5.5.
-
-### A.7.7 DWARF Expressions
-
-> NOTE: Rename DWARF Version 5 section 7.7 to reflect the unification of
-> location descriptions into DWARF expressions.
-
-#### A.7.7.1 Operation Expressions
-
-> NOTE: Rename DWARF Version 5 section 7.7.1 and delete section 7.7.2 to reflect
-> the unification of location descriptions into DWARF expressions.
-
-#### A.7.7.3 Location List Expressions
-
-> NOTE: Rename DWARF Version 5 section 7.7.3 to reflect that location lists are
-> a kind of DWARF expression.
-
-# B. Further Information
-
-The following references provide additional information on the extension.
-
-A reference to the DWARF standard is provided.
-
-A formatted version of this extension is available on the LLVM site. It includes
-many figures that help illustrate the textual description, especially of the
-example DWARF expression evaluations.
-
-Slides and a video of a presentation at the Linux Plumbers Conference 2021
-related to this extension are available.
-
-The LLVM compiler extension includes the operations mentioned in the motivating
-examples. It also covers other extensions needed for heterogeneous devices.
-
-- [DWARF Debugging Information Format](https://dwarfstd.org/)
-  - [DWARF Debugging Information Format Version 5](https://dwarfstd.org/Dwarf5Std.php)
-- [Allow Location Descriptions on the DWARF Expression Stack](https://llvm.org/docs/AMDGPUDwarfExtensionAllowLocationDescriptionOnTheDwarfExpressionStack/AMDGPUDwarfExtensionAllowLocationDescriptionOnTheDwarfExpressionStack.html)
-- DWARF extensions for optimized SIMT/SIMD (GPU) debugging - Linux Plumbers Conference 2021
-  - [Video](https://www.youtube.com/watch?v=QiR0ra0ymEY&t=10015s)
-  - [Slides](https://linuxplumbersconf.org/event/11/contributions/1012/attachments/798/1505/DWARF_Extensions_for_Optimized_SIMT-SIMD_GPU_Debugging-LPC2021.pdf)
-- [DWARF Extensions For Heterogeneous Debugging](https://llvm.org/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.html)
+# Allow Location Descriptions on the DWARF Expression Stack <!-- omit in toc -->
+
+- [1. Extension](#extension)
+- [2. Heterogeneous Computing Devices](#heterogeneous-computing-devices)
+- [3. DWARF 5](#dwarf-5)
+  - [3.1 How DWARF Maps Source Language To Hardware](#how-dwarf-maps-source-language-to-hardware)
+  - [3.2 Examples](#examples)
+    - [3.2.1 Dynamic Array Size](#dynamic-array-size)
+    - [3.2.2 Variable Location in Register](#variable-location-in-register)
+    - [3.2.3 Variable Location in Memory](#variable-location-in-memory)
+    - [3.2.4 Variable Spread Across Different Locations](#variable-spread-across-different-locations)
+    - [3.2.5 Offsetting a Composite Location](#offsetting-a-composite-location)
+  - [3.3 Limitations](#limitations)
+- [4. Extension Solution](#extension-solution)
+  - [4.1 Location Description](#location-description)
+  - [4.2 Stack Location Description Operations](#stack-location-description-operations)
+  - [4.3 Examples](#examples-1)
+    - [4.3.1 Source Language Variable Spilled to Part of a Vector Register](#source-language-variable-spilled-to-part-of-a-vector-register)
+    - [4.3.2 Source Language Variable Spread Across Multiple Vector Registers](#source-language-variable-spread-across-multiple-vector-registers)
+    - [4.3.3 Source Language Variable Spread Across Multiple Kinds of Locations](#source-language-variable-spread-across-multiple-kinds-of-locations)
+    - [4.3.4 Address Spaces](#address-spaces)
+    - [4.3.5 Bit Offsets](#bit-offsets)
+  - [4.4 Call Frame Information (CFI)](#call-frame-information-cfi)
+  - [4.5 Objects Not In Byte Aligned Global Memory](#objects-not-in-byte-aligned-global-memory)
+  - [4.6 Higher Order Operations](#higher-order-operations)
+  - [4.7 Objects In Multiple Places](#objects-in-multiple-places)
+- [5. Conclusion](#conclusion)
+- [A. Changes to DWARF Debugging Information Format Version 5](#a-changes-to-dwarf-debugging-information-format-version-5)
+  - [A.2 General Description](#a-2-general-description)
+    - [A.2.5 DWARF Expressions](#a-2-5-dwarf-expressions)
+      - [A.2.5.1 DWARF Expression Evaluation Context](#a-2-5-1-dwarf-expression-evaluation-context)
+      - [A.2.5.2 DWARF Expression Value](#a-2-5-2-dwarf-expression-value)
+      - [A.2.5.3 DWARF Location Description](#a-2-5-3-dwarf-location-description)
+      - [A.2.5.4 DWARF Operation Expressions](#a-2-5-4-dwarf-operation-expressions)
+        - [A.2.5.4.1 Stack Operations](#a-2-5-4-1-stack-operations)
+        - [A.2.5.4.2 Control Flow Operations](#a-2-5-4-2-control-flow-operations)
+        - [A.2.5.4.3 Value Operations](#a-2-5-4-3-value-operations)
+          - [A.2.5.4.3.1 Literal Operations](#a-2-5-4-3-1-literal-operations)
+          - [A.2.5.4.3.2 Arithmetic and Logical Operations](#a-2-5-4-3-2-arithmetic-and-logical-operations)
+          - [A.2.5.4.3.3 Type Conversion Operations](#a-2-5-4-3-3-type-conversion-operations)
+          - [A.2.5.4.3.4 Special Value Operations](#a-2-5-4-3-4-special-value-operations)
+        - [A.2.5.4.4 Location Description Operations](#a-2-5-4-4-location-description-operations)
+          - [A.2.5.4.4.1 General Location Description Operations](#a-2-5-4-4-1-general-location-description-operations)
+          - [A.2.5.4.4.2 Undefined Location Description Operations](#a-2-5-4-4-2-undefined-location-description-operations)
+          - [A.2.5.4.4.3 Memory Location Description Operations](#a-2-5-4-4-3-memory-location-description-operations)
+          - [A.2.5.4.4.4 Register Location Description Operations](#a-2-5-4-4-4-register-location-description-operations)
+          - [A.2.5.4.4.5 Implicit Location Description Operations](#a-2-5-4-4-5-implicit-location-description-operations)
+          - [A.2.5.4.4.6 Composite Location Description Operations](#a-2-5-4-4-6-composite-location-description-operations)
+      - [A.2.5.5 DWARF Location List Expressions](#a-2-5-5-dwarf-location-list-expressions)
+  - [A.3 Program Scope Entries](#a-3-program-scope-entries)
+    - [A.3.3 Subroutine and Entry Point Entries](#a-3-3-subroutine-and-entry-point-entries)
+      - [A.3.3.5 Low-Level Information](#a-3-3-5-low-level-information)
+    - [A.3.4 Call Site Entries and Parameters](#a-3-4-call-site-entries-and-parameters)
+      - [A.3.4.2 Call Site Parameters](#a-3-4-2-call-site-parameters)
+    - [A.3.5 Lexical Block Entries](#a-3-5-lexical-block-entries)
+  - [A.4 Data Object and Object List Entries](#a-4-data-object-and-object-list-entries)
+    - [A.4.1 Data Object Entries](#a-4-1-data-object-entries)
+  - [A.5 Type Entries](#a-5-type-entries)
+    - [A.5.7 Structure, Union, Class and Interface Type Entries](#a-5-7-structure-union-class-and-interface-type-entries)
+      - [A.5.7.3 Derived or Extended Structures, Classes and Interfaces](#a-5-7-3-derived-or-extended-structures-classes-and-interfaces)
+      - [A.5.7.8 Member Function Entries](#a-5-7-8-member-function-entries)
+    - [A.5.14 Pointer to Member Type Entries](#a-5-14-pointer-to-member-type-entries)
+    - [A.5.16 Dynamic Type Entries](#a-5-16-dynamic-type-entries)
+  - [A.6 Other Debugging Information](#a-6-other-debugging-information)
+    - [A.6.2 Line Number Information](#a-6-2-line-number-information)
+    - [A.6.4 Call Frame Information](#a-6-4-call-frame-information)
+      - [A.6.4.1 Structure of Call Frame Information](#a-6-4-1-structure-of-call-frame-information)
+      - [A.6.4.2 Call Frame Instructions](#a-6-4-2-call-frame-instructions)
+        - [A.6.4.2.1 Row Creation Instructions](#a-6-4-2-1-row-creation-instructions)
+        - [A.6.4.2.2 CFA Definition Instructions](#a-6-4-2-2-cfa-definition-instructions)
+        - [A.6.4.2.3 Register Rule Instructions](#a-6-4-2-3-register-rule-instructions)
+        - [A.6.4.2.4 Row State Instructions](#a-6-4-2-4-row-state-instructions)
+        - [A.6.4.2.5 Padding Instruction](#a-6-4-2-5-padding-instruction)
+      - [A.6.4.3 Call Frame Instruction Usage](#a-6-4-3-call-frame-instruction-usage)
+      - [A.6.4.4 Call Frame Calling Address](#a-6-4-4-call-frame-calling-address)
+  - [A.7 Data Representation](#a-7-data-representation)
+    - [A.7.4 32-Bit and 64-Bit DWARF Formats](#a-7-4-32-bit-and-64-bit-dwarf-formats)
+    - [A.7.5 Format of Debugging Information](#a-7-5-format-of-debugging-information)
+      - [A.7.5.5 Classes and Forms](#a-7-5-5-classes-and-forms)
+    - [A.7.7 DWARF Expressions](#a-7-7-dwarf-expressions)
+      - [A.7.7.1 Operation Expressions](#a-7-7-1-operation-expressions)
+      - [A.7.7.3 Location List Expressions](#a-7-7-3-location-list-expressions)
+- [B. Further Information](#b-further-information)
+
+# 1. Extension
+
+In DWARF 5, expressions are evaluated using a typed value stack, a separate
+location area, and an independent loclist mechanism. This extension unifies all
+three mechanisms into a single generalized DWARF expression evaluation model
+that allows both typed values and location descriptions to be manipulated on the
+evaluation stack. Both single and multiple location descriptions are supported
+on the stack. In addition, the call frame information (CFI) is extended to
+support the full generality of location descriptions. This is done in a manner
+that is backwards compatible with DWARF 5. The extension involves changes to the
+DWARF 5 sections 2.5 (pp 26-38), 2.6 (pp 38-45), and 6.4 (pp 171-182).
+
+The extension permits operations to act on location descriptions in an
+incremental, consistent, and composable manner. It allows a small number of
+operations to be defined to address the requirements of heterogeneous devices as
+well as providing benefits to non-heterogeneous devices. It acts as a foundation
+to provide support for other issues that have been raised that would benefit all
+devices.
+
+Other approaches were explored that involved adding specialized operations and
+rules. However, these resulted in the need for more operations that did not
+compose. It also resulted in operations with context sensitive semantics and
+corner cases that had to be defined. The observation was that numerous
+specialized context sensitive operations are harder for both produces and
+consumers than a smaller number of general composable operations that have
+consistent semantics regardless of context.
+
+First, section [2. Heterogeneous Computing
+Devices](#heterogeneous-computing-devices) describes heterogeneous devices and
+the features they have that are not addressed by DWARF 5. Then section [3. DWARF
+5](#dwarf-5) presents a brief simplified overview of the DWARF 5 expression
+evaluation model that highlights the difficulties for supporting the
+heterogeneous features. Next, section [4. Extension
+Solution](#extension-solution) provides an overview of the proposal, using
+simplified examples to illustrate how it can address the issues of heterogeneous
+devices and also benefit non-heterogeneous devices. Then overall conclusions are
+covered in section [5. Conclusion](#conclusion). Appendix [A. Changes to DWARF
+Debugging Information Format Version
+5](#a-changes-to-dwarf-debugging-information-format-version-5) gives changes
+relative to the DWARF Version 5 standard. Finally, appendix [B. Further
+Information](#b-further-information) has references to further information.
+
+# 2. Heterogeneous Computing Devices
+
+GPUs and other heterogeneous computing devices have features not common to CPU
+computing devices.
+
+These devices often have many more registers than a CPU. This helps reduce
+memory accesses which tend to be more expensive than on a CPU due to the much
+larger number of threads concurrently executing. In addition to traditional
+scalar registers of a CPU, these devices often have many wide vector registers.
+
+![Example GPU Hardware](images/example-gpu-hardware.png)
+
+They may support masked vector instructions that are used by the compiler to map
+high level language threads onto the lanes of the vector registers. As a
+consequence, multiple language threads execute in lockstep as the vector
+instructions are executed. This is termed single instruction multiple thread
+(SIMT) execution.
+
+![SIMT/SIMD Execution Model](images/simt-execution-model.png)
+
+GPUs can have multiple memory address spaces in addition to the single global
+memory address space of a CPU. These additional address spaces are accessed
+using distinct instructions and are often local to a particular thread or group
+of threads.
+
+For example, a GPU may have a per thread block address space that is implemented
+as scratch pad memory with explicit hardware support to isolate portions to
+specific groups of threads created as a single thread block.
+
+A GPU may also use global memory in a non linear manner. For example, to support
+providing a SIMT per lane address space efficiently, there may be instructions
+that support interleaved access.
+
+Through optimization, the source variables may be located across these different
+storage kinds. SIMT execution requires locations to be able to express selection
+of runtime defined pieces of vector registers. With the more complex locations,
+there is a benefit to be able to factorize their calculation which requires all
+location kinds to be supported uniformly, otherwise duplication is necessary.
+
+# 3. DWARF 5
+
+Before presenting the proposed solution to supporting heterogeneous devices, a
+brief overview of the DWARF 5 expression evaluation model will be given to
+highlight the aspects being addressed by the extension.
+
+## 3.1 How DWARF Maps Source Language To Hardware
+
+DWARF is a standardized way to specify debug information. It describes source
+language entities such as compilation units, functions, types, variables, etc.
+It is either embedded directly in sections of the code object executables, or
+split into separate files that they reference.
+
+DWARF maps between source program language entities and their hardware
+representations. For example:
+
+- It maps a hardware instruction program counter to a source language program
+  line, and vice versa.
+- It maps a source language function to the hardware instruction program counter
+  for its entry point.
+- It maps a source language variable to its hardware location when at a
+  particular program counter.
+- It provides information to allow virtual unwinding of hardware registers for a
+  source language function call stack.
+- In addition, it provides numerous other information about the source language
+  program.
+
+In particular, there is great diversity in the way a source language entity
+could be mapped to a hardware location. The location may involve runtime values.
+For example, a source language variable location could be:
+
+- In register.
+- At a memory address.
+- At an offset from the current stack pointer.
+- Optimized away, but with a known compiler time value.
+- Optimized away, but with an unknown value, such as happens for unused
+  variables.
+- Spread across combination of the above kinds of locations.
+- At a memory address, but also transiently loaded into registers.
+
+To support this DWARF 5 defines a rich expression language comprised of loclist
+expressions and operation expressions. Loclist expressions allow the result to
+vary depending on the PC. Operation expressions are made up of a list of
+operations that are evaluated on a simple stack machine.
+
+A DWARF expression can be used as the value of different attributes of different
+debug information entries (DIE). A DWARF expression can also be used as an
+argument to call frame information information (CFI) entry operations. An
+expression is evaluated in a context dictated by where it is used. The context
+may include:
+
+- Whether the expression needs to produce a value or the location of an entity.
+- The current execution point including process, thread, PC, and stack frame.
+- Some expressions are evaluated with the stack initialized with a specific
+  value or with the location of a base object that is available using the
+  DW_OP_push_object_address operation.
+
+## 3.2 Examples
+
+The following examples illustrate how DWARF expressions involving operations are
+evaluated in DWARF 5. DWARF also has expressions involving location lists that
+are not covered in these examples.
+
+### 3.2.1 Dynamic Array Size
+
+The first example is for an operation expression associated with a DIE attribute
+that provides the number of elements in a dynamic array type. Such an attribute
+dictates that the expression must be evaluated in the context of providing a
+value result kind.
+
+![Dynamic Array Size Example](images/01-value.example.png)
+
+In this hypothetical example, the compiler has allocated an array descriptor in
+memory and placed the descriptor's address in architecture register SGPR0. The
+first location of the array descriptor is the runtime size of the array.
+
+A possible expression to retrieve the dynamic size of the array is:
+
+    DW_OP_regval_type SGPR0 Generic
+    DW_OP_deref
+
+The expression is evaluated one operation at a time. Operations have operands
+and can pop and push entries on a stack.
+
+![Dynamic Array Size Example: Step 1](images/01-value.example.frame.1.png)
+
+The expression evaluation starts with the first DW_OP_regval_type operation.
+This operation reads the current value of an architecture register specified by
+its first operand: SGPR0. The second operand specifies the size of the data to
+read. The read value is pushed on the stack. Each stack element is a value and
+its associated type.
+
+![Dynamic Array Size Example: Step 2](images/01-value.example.frame.2.png)
+
+The type must be a DWARF base type. It specifies the encoding, byte ordering,
+and size of values of the type. DWARF defines that each architecture has a
+default generic type: it is an architecture specific integral encoding and byte
+ordering, that is the size of the architecture's global memory address.
+
+The DW_OP_deref operation pops a value off the stack, treats it as a global
+memory address, and reads the contents of that location using the generic type.
+It pushes the read value on the stack as the value and its associated generic
+type.
+
+![Dynamic Array Size Example: Step 3](images/01-value.example.frame.3.png)
+
+The evaluation stops when it reaches the end of the expression. The result of an
+expression that is evaluated with a value result kind context is the top element
+of the stack, which provides the value and its type.
+
+### 3.2.2 Variable Location in Register
+
+This example is for an operation expression associated with a DIE attribute that
+provides the location of a source language variable. Such an attribute dictates
+that the expression must be evaluated in the context of providing a location
+result kind.
+
+DWARF defines the locations of objects in terms of location descriptions.
+
+In this example, the compiler has allocated a source language variable in
+architecture register SGPR0.
+
+![Variable Location in Register Example](images/02-reg.example.png)
+
+A possible expression to specify the location of the variable is:
+
+    DW_OP_regx SGPR0
+
+![Variable Location in Register Example: Step 1](images/02-reg.example.frame.1.png)
+
+The DW_OP_regx operation creates a location description that specifies the
+location of the architecture register specified by the operand: SGPR0. Unlike
+values, location descriptions are not pushed on the stack. Instead they are
+conceptually placed in a location area. Unlike values, location descriptions do
+not have an associated type, they only denote the location of the base of the
+object.
+
+![Variable Location in Register Example: Step 2](images/02-reg.example.frame.2.png)
+
+Again, evaluation stops when it reaches the end of the expression. The result of
+an expression that is evaluated with a location result kind context is the
+location description in the location area.
+
+### 3.2.3 Variable Location in Memory
+
+The next example is for an operation expression associated with a DIE attribute
+that provides the location of a source language variable that is allocated in a
+stack frame. The compiler has placed the stack frame pointer in architecture
+register SGPR0, and allocated the variable at offset 0x10 from the stack frame
+base. The stack frames are allocated in global memory, so SGPR0 contains a
+global memory address.
+
+![Variable Location in Memory Example](images/03-memory.example.png)
+
+A possible expression to specify the location of the variable is:
+
+    DW_OP_regval_type SGPR0 Generic
+    DW_OP_plus_uconst 0x10
+
+![Variable Location in Memory Example: Step 1](images/03-memory.example.frame.1.png)
+
+As in the previous example, the DW_OP_regval_type operation pushes the stack
+frame pointer global memory address onto the stack. The generic type is the size
+of a global memory address.
+
+![Variable Location in Memory Example: Step 2](images/03-memory.example.frame.2.png)
+
+The DW_OP_plus_uconst operation pops a value from the stack, which must have a
+type with an integral encoding, adds the value of its operand, and pushes the
+result back on the stack with the same associated type. In this example, that
+computes the global memory address of the source language variable.
+
+![Variable Location in Memory Example: Step 3](images/03-memory.example.frame.3.png)
+
+Evaluation stops when it reaches the end of the expression. If the expression
+that is evaluated has a location result kind context, and the location area is
+empty, then the top stack element must be a value with the generic type. The
+value is implicitly popped from the stack, and treated as a global memory
+address to create a global memory location description, which is placed in the
+location area. The result of the expression is the location description in the
+location area.
+
+![Variable Location in Memory Example: Step 4](images/03-memory.example.frame.4.png)
+
+### 3.2.4 Variable Spread Across Different Locations
+
+This example is for a source variable that is partly in a register, partly undefined, and partly in memory.
+
+![Variable Spread Across Different Locations Example](images/04-composite.example.png)
+
+DWARF defines composite location descriptions that can have one or more parts.
+Each part specifies a location description and the number of bytes used from it.
+The following operation expression creates a composite location description.
+
+    DW_OP_regx SGPR3
+    DW_OP_piece 4
+    DW_OP_piece 2
+    DW_OP_bregx SGPR0 0x10
+    DW_OP_piece 2
+
+![Variable Spread Across Different Locations Example: Step 1](images/04-composite.example.frame.1.png)
+
+The DW_OP_regx operation creates a register location description in the location
+area.
+
+![Variable Spread Across Different Locations Example: Step 2](images/04-composite.example.frame.2.png)
+
+The first DW_OP_piece operation creates an incomplete composite location
+description in the location area with a single part. The location description in
+the location area is used to define the beginning of the part for the size
+specified by the operand, namely 4 bytes.
+
+![Variable Spread Across Different Locations Example: Step 3](images/04-composite.example.frame.3.png)
+
+A subsequent DW_OP_piece adds a new part to an incomplete composite location
+description already in the location area. The parts form a contiguous set of
+bytes. If there are no other location descriptions in the location area, and no
+value on the stack, then the part implicitly uses the undefined location
+description. Again, the operand specifies the size of the part in bytes. The
+undefined location description can be used to indicate a part that has been
+optimized away. In this case, 2 bytes of undefined value.
+
+![Variable Spread Across Different Locations Example: Step 4](images/04-composite.example.frame.4.png)
+
+The DW_OP_bregx operation reads the architecture register specified by the first
+operand (SGPR0) as the generic type, adds the value of the second operand
+(0x10), and pushes the value on the stack.
+
+![Variable Spread Across Different Locations Example: Step 5](images/04-composite.example.frame.5.png)
+
+The next DW_OP_piece operation adds another part to the already created
+incomplete composite location.
+
+If there is no other location in the location area, but there is a value on
+stack, the new part is a memory location description. The memory address used is
+popped from the stack. In this case, the operand of 2 indicates there are 2
+bytes from memory.
+
+![Variable Spread Across Different Locations Example: Step 6](images/04-composite.example.frame.6.png)
+
+Evaluation stops when it reaches the end of the expression. If the expression
+that is evaluated has a location result kind context, and the location area has
+an incomplete composite location description, the incomplete composite location
+is implicitly converted to a complete composite location description. The result
+of the expression is the location description in the location area.
+
+![Variable Spread Across Different Locations Example: Step 7](images/04-composite.example.frame.7.png)
+
+### 3.2.5 Offsetting a Composite Location
+
+This example attempts to extend the previous example to offset the composite
+location description it created. The [3.2.3 Variable Location in
+Memory](#variable-location-in-memory) example conveniently used the DW_OP_plus
+operation to offset a memory address.
+
+    DW_OP_regx SGPR3
+    DW_OP_piece 4
+    DW_OP_piece 2
+    DW_OP_bregx SGPR0 0x10
+    DW_OP_piece 2
+    DW_OP_plus_uconst 5
+
+![Offsetting a Composite Location Example: Step 6](images/05-composite-plus.example.frame.1.png)
+
+However, DW_OP_plus cannot be used to offset a composite location. It only
+operates on the stack.
+
+![Offsetting a Composite Location Example: Step 7](images/05-composite-plus.example.frame.2.png)
+
+To offset a composite location description, the compiler would need to make a
+different composite location description, starting at the part corresponding to
+the offset. For example:
+
+    DW_OP_piece 1
+    DW_OP_bregx SGPR0 0x10
+    DW_OP_piece 2
+
+This illustrates that operations on stack values are not composable with
+operations on location descriptions.
+
+## 3.3 Limitations
+
+DWARF 5 is unable to describe variables in runtime indexed parts of registers.
+This is required to describe a source variable that is located in a lane of a
+SIMT vector register.
+
+Some features only work when located in global memory. The type attribute
+expressions require a base object which could be in any kind of location.
+
+DWARF procedures can only accept global memory address arguments. This limits
+the ability to factorize the creation of locations that involve other location
+kinds.
+
+There are no vector base types. This is required to describe vector registers.
+
+There is no operation to create a memory location in a non-global address space.
+Only the dereference operation supports providing an address space.
+
+CFI location expressions do not allow composite locations or non-global address
+space memory locations. Both these are needed in optimized code for devices with
+vector registers and address spaces.
+
+Bit field offsets are only supported in a limited way for register locations.
+Supporting them in a uniform manner for all location kinds is required to
+support languages with bit sized entities.
+
+# 4. Extension Solution
+
+This section outlines the extension to generalize the DWARF expression evaluation
+model to allow location descriptions to be manipulated on the stack. It presents
+a number of simplified examples to demonstrate the benefits and how the extension
+solves the issues of heterogeneous devices. It presents how this is done in
+a manner that is backwards compatible with DWARF 5.
+
+## 4.1 Location Description
+
+In order to have consistent, composable operations that act on location
+descriptions, the extension defines a uniform way to handle all location kinds.
+That includes memory, register, implicit, implicit pointer, undefined, and
+composite location descriptions.
+
+Each kind of location description is conceptually a zero-based offset within a
+piece of storage. The storage is a contiguous linear organization of a certain
+number of bytes (see below for how this is extended to support bit sized
+storage).
+
+- For global memory, the storage is the linear stream of bytes of the
+  architecture's address size.
+- For each separate architecture register, it is the linear stream of bytes of
+  the size of that specific register.
+- For an implicit, it is the linear stream of bytes of the value when
+  represented using the value's base type which specifies the encoding, size,
+  and byte ordering.
+- For undefined, it is an infinitely sized linear stream where every byte is
+  undefined.
+- For composite, it is a linear stream of bytes defined by the composite's parts.
+
+## 4.2 Stack Location Description Operations
+
+The DWARF expression stack is extended to allow each stack entry to either be a
+value or a location description.
+
+Evaluation rules are defined to implicitly convert a stack element that is a
+value to a location description, or vice versa, so that all DWARF 5 expressions
+continue to have the same semantics. This reflects that a memory address is
+effectively used as a proxy for a memory location description.
+
+For each place that allows a DWARF expression to be specified, it is defined if
+the expression is to be evaluated as a value or a location description.
+
+Existing DWARF expression operations that are used to act on memory addresses
+are generalized to act on any location description kind. For example, the
+DW_OP_deref operation pops a location description rather than a memory address
+value from the stack and reads the storage associated with the location kind
+starting at the location description's offset.
+
+Existing DWARF expression operations that create location descriptions are
+changed to pop and push location descriptions on the stack. For example, the
+DW_OP_value, DW_OP_regx, DW_OP_implicit_value, DW_OP_implicit_pointer,
+DW_OP_stack_value, and DW_OP_piece.
+
+New operations that act on location descriptions can be added. For example, a
+DW_OP_offset operation that modifies the offset of the location description on
+top of the stack. Unlike the DW_OP_plus operation that only works with memory
+address, a DW_OP_offset operation can work with any location kind.
+
+To allow incremental and nested creation of composite location descriptions, a
+DW_OP_piece_end can be defined to explicitly indicate the last part of a
+composite. Currently, creating a composite must always be the last operation of
+an expression.
+
+A DW_OP_undefined operation can be defined that explicitly creates the undefined
+location description. Currently this is only possible as a piece of a composite
+when the stack is empty.
+
+## 4.3 Examples
+
+This section provides some motivating examples to illustrate the benefits that
+result from allowing location descriptions on the stack.
+
+### 4.3.1 Source Language Variable Spilled to Part of a Vector Register
+
+A compiler generating code for a GPU may allocate a source language variable
+that it proves has the same value for every lane of a SIMT thread in a scalar
+register. It may then need to spill that scalar register. To avoid the high cost
+of spilling to memory, it may spill to a fixed lane of one of the numerous
+vector registers.
+
+![Source Language Variable Spilled to Part of a Vector Register Example](images/06-extension-spill-sgpr-to-static-vpgr-lane.example.png)
+
+The following expression defines the location of a source language variable that
+the compiler allocated in a scalar register, but had to spill to lane 5 of a
+vector register at this point of the code.
+
+    DW_OP_regx VGPR0
+    DW_OP_offset_uconst 20
+
+![Source Language Variable Spilled to Part of a Vector Register Example: Step 1](images/06-extension-spill-sgpr-to-static-vpgr-lane.example.frame.1.png)
+
+The DW_OP_regx pushes a register location description on the stack. The storage
+for the register is the size of the vector register. The register location
+description conceptually references that storage with an initial offset of 0.
+The architecture defines the byte ordering of the register.
+
+![Source Language Variable Spilled to Part of a Vector Register Example: Step 2](images/06-extension-spill-sgpr-to-static-vpgr-lane.example.frame.2.png)
+
+The DW_OP_offset_uconst pops a location description off the stack, adds its
+operand value to the offset, and pushes the updated location description back on
+the stack. In this case the source language variable is being spilled to lane 5
+and each lane's component which is 32-bits (4 bytes), so the offset is 5*4=20.
+
+![Source Language Variable Spilled to Part of a Vector Register Example: Step 3](images/06-extension-spill-sgpr-to-static-vpgr-lane.example.frame.3.png)
+
+The result of the expression evaluation is the location description on the top
+of the stack.
+
+An alternative approach could be for the target to define distinct register
+names for each part of each vector register. However, this is not practical for
+GPUs due to the sheer number of registers that would have to be defined. It
+would also not permit a runtime index into part of the whole register to be used
+as shown in the next example.
+
+### 4.3.2 Source Language Variable Spread Across Multiple Vector Registers
+
+A compiler may generate SIMT code for a GPU. Each source language thread of
+execution is mapped to a single lane of the GPU thread. Source language
+variables that are mapped to a register, are mapped to the lane component of the
+vector registers corresponding to the source language's thread of execution.
+
+The location expression for such variables must therefore be executed in the
+context of the focused source language thread of execution. A DW_OP_push_lane
+operation can be defined to push the value of the lane for the currently focused
+source language thread of execution. The value to use would be provided by the
+consumer of DWARF when it evaluates the location expression.
+
+If the source language variable is larger than the size of the vector register
+lane component, then multiple vector registers are used. Each source language
+thread of execution will only use the vector register components for its
+associated lane.
+
+![Source Language Variable Spread Across Multiple Vector Registers Example](images/07-extension-multi-lane-vgpr.example.png)
+
+The following expression defines the location of a source language variable that
+has to occupy two vector registers. A composite location description is created
+that combines the two parts. It will give the correct result regardless of which
+lane corresponds to the source language thread of execution that the user is
+focused on.
+
+    DW_OP_regx VGPR0
+    DW_OP_push_lane
+    DW_OP_uconst 4
+    DW_OP_mul
+    DW_OP_offset
+    DW_OP_piece 4
+    DW_OP_regx VGPR1
+    DW_OP_push_lane
+    DW_OP_uconst 4
+    DW_OP_mul
+    DW_OP_offset
+    DW_OP_piece 4
+
+![Source Language Variable Spread Across Multiple Vector Registers Example: Step 1](images/07-extension-multi-lane-vgpr.example.frame.1.png)
+
+The DW_OP_regx VGPR0 pushes a location description for the first register.
+
+![Source Language Variable Spread Across Multiple Vector Registers Example: Step 2](images/07-extension-multi-lane-vgpr.example.frame.2.png)
+
+The DW_OP_push_lane; DW_OP_uconst 4; DW_OP_mul calculates the offset for the
+focused lanes vector register component as 4 times the lane number.
+
+![Source Language Variable Spread Across Multiple Vector Registers Example: Step 3](images/07-extension-multi-lane-vgpr.example.frame.3.png)
+
+![Source Language Variable Spread Across Multiple Vector Registers Example: Step 4](images/07-extension-multi-lane-vgpr.example.frame.4.png)
+
+![Source Language Variable Spread Across Multiple Vector Registers Example: Step 5](images/07-extension-multi-lane-vgpr.example.frame.5.png)
+
+The DW_OP_offset adjusts the register location description's offset to the
+runtime computed value.
+
+![Source Language Variable Spread Across Multiple Vector Registers Example: Step 6](images/07-extension-multi-lane-vgpr.example.frame.6.png)
+
+The DW_OP_piece either creates a new composite location description, or adds a
+new part to an existing incomplete one. It pops the location description to use
+for the new part. It then pops the next stack element if it is an incomplete
+composite location description, otherwise it creates a new incomplete composite
+location description with no parts. Finally it pushes the incomplete composite
+after adding the new part.
+
+In this case a register location description is added to a new incomplete
+composite location description. The 4 of the DW_OP_piece specifies the size of
+the register storage that comprises the part. Note that the 4 bytes start at the
+computed register offset.
+
+For backwards compatibility, if the stack is empty or the top stack element is
+an incomplete composite, an undefined location description is used for the part.
+If the top stack element is a generic base type value, then it is implicitly
+converted to a global memory location description with an offset equal to the
+value.
+
+![Source Language Variable Spread Across Multiple Vector Registers Example: Step 7](images/07-extension-multi-lane-vgpr.example.frame.7.png)
+
+The rest of the expression does the same for VGPR1. However, when the
+DW_OP_piece is evaluated there is an incomplete composite on the stack. So the
+VGPR1 register location description is added as a second part.
+
+![Source Language Variable Spread Across Multiple Vector Registers Example: Step 8](images/07-extension-multi-lane-vgpr.example.frame.8.png)
+
+![Source Language Variable Spread Across Multiple Vector Registers Example: Step 9](images/07-extension-multi-lane-vgpr.example.frame.9.png)
+
+![Source Language Variable Spread Across Multiple Vector Registers Example: Step 10](images/07-extension-multi-lane-vgpr.example.frame.10.png)
+
+![Source Language Variable Spread Across Multiple Vector Registers Example: Step 11](images/07-extension-multi-lane-vgpr.example.frame.11.png)
+
+![Source Language Variable Spread Across Multiple Vector Registers Example: Step 12](images/07-extension-multi-lane-vgpr.example.frame.12.png)
+
+![Source Language Variable Spread Across Multiple Vector Registers Example: Step 13](images/07-extension-multi-lane-vgpr.example.frame.13.png)
+
+At the end of the expression, if the top stack element is an incomplete
+composite location description, it is converted to a complete location
+description and returned as the result.
+
+![Source Language Variable Spread Across Multiple Vector Registers Example: Step 14](images/07-extension-multi-lane-vgpr.example.frame.14.png)
+
+### 4.3.3 Source Language Variable Spread Across Multiple Kinds of Locations
+
+This example is the same as the previous one, except the first 2 bytes of the
+second vector register have been spilled to memory, and the last 2 bytes have
+been proven to be a constant and optimized away.
+
+![Source Language Variable Spread Across Multiple Kinds of Locations Example](images/08-extension-mixed-composite.example.png)
+
+    DW_OP_regx VGPR0
+    DW_OP_push_lane
+    DW_OP_uconst 4
+    DW_OP_mul
+    DW_OP_offset
+    DW_OP_piece 4
+    DW_OP_addr 0xbeef
+    DW_OP_piece 2
+    DW_OP_uconst 0xf00d
+    DW_OP_stack_value
+    DW_OP_piece 2
+    DW_OP_piece_end
+
+The first 6 operations are the same.
+
+![Source Language Variable Spread Across Multiple Kinds of Locations Example: Step 7](images/08-extension-mixed-composite.example.frame.1.png)
+
+The DW_OP_addr operation pushes a global memory location description on the
+stack with an offset equal to the address.
+
+![Source Language Variable Spread Across Multiple Kinds of Locations Example: Step 8](images/08-extension-mixed-composite.example.frame.2.png)
+
+The next DW_OP_piece adds the global memory location description as the next 2
+byte part of the composite.
+
+![Source Language Variable Spread Across Multiple Kinds of Locations Example: Step 9](images/08-extension-mixed-composite.example.frame.3.png)
+
+The DW_OP_uconst 0xf00d; DW_OP_stack_value pushes an implicit location
+description on the stack. The storage of the implicit location description is
+the representation of the value 0xf00d using the generic base type's encoding,
+size, and byte ordering.
+
+![Source Language Variable Spread Across Multiple Kinds of Locations Example: Step 10](images/08-extension-mixed-composite.example.frame.4.png)
+
+![Source Language Variable Spread Across Multiple Kinds of Locations Example: Step 11](images/08-extension-mixed-composite.example.frame.5.png)
+
+The final DW_OP_piece adds 2 bytes of the implicit location description as the
+third part of the composite location description.
+
+![Source Language Variable Spread Across Multiple Kinds of Locations Example: Step 12](images/08-extension-mixed-composite.example.frame.6.png)
+
+The DW_OP_piece_end operation explicitly makes the incomplete composite location
+description into a complete location description. This allows a complete
+composite location description to be created on the stack that can be used as
+the location description of another following operation. For example, the
+DW_OP_offset can be applied to it. More practically, it permits creation of
+multiple composite location descriptions on the stack which can be used to pass
+arguments to a DWARF procedure using a DW_OP_call* operation. This can be
+beneficial to factor the incrementally creation of location descriptions.
+
+![Source Language Variable Spread Across Multiple Kinds of Locations Example: Step 12](images/08-extension-mixed-composite.example.frame.7.png)
+
+### 4.3.4 Address Spaces
+
+Heterogeneous devices can have multiple hardware supported address spaces which
+use specific hardware instructions to access them.
+
+For example, GPUs that use SIMT execution may provide hardware support to access
+memory such that each lane can see a linear memory view, while the backing
+memory is actually being accessed in an interleaved manner so that the locations
+for each lanes Nth dword are contiguous. This minimizes cache lines read by the
+SIMT execution.
+
+![Address Spaces Example](images/09-extension-form-aspace.example.png)
+
+The following expression defines the location of a source language variable that
+is allocated at offset 0x10 in the current subprograms stack frame. The
+subprogram stack frames are per lane and reside in an interleaved address space.
+
+    DW_OP_regval_type SGPR0 Generic
+    DW_OP_uconst 1
+    DW_OP_form_aspace_address
+    DW_OP_offset 0x10
+
+![Address Spaces Example: Step 1](images/09-extension-form-aspace.example.frame.1.png)
+
+The DW_OP_regval_type operation pushes the contents of SGPR0 as a generic value.
+This is the register that holds the address of the current stack frame.
+
+![Address Spaces Example: Step 2](images/09-extension-form-aspace.example.frame.2.png)
+
+The DW_OP_uconst operation pushes the address space number. Each architecture
+defines the numbers it uses in DWARF. In this case, address space 1 is being
+used as the per lane memory.
+
+![Address Spaces Example: Step 3](images/09-extension-form-aspace.example.frame.3.png)
+
+The DW_OP_form_aspace_address operation pops a value and an address space
+number. Each address space is associated with a separate storage. A memory
+location description is pushed which refers to the address space's storage, with
+an offset of the popped value.
+
+![Address Spaces Example: Step 4](images/09-extension-form-aspace.example.frame.4.png)
+
+All operations that act on location descriptions work with memory locations
+regardless of their address space.
+
+Every architecture defines address space 0 as the default global memory address
+space.
+
+Generalizing memory location descriptions to include an address space component
+avoids having to create specialized operations to work with address spaces.
+
+The source variable is at offset 0x10 in the stack frame. The DW_OP_offset
+operation works on memory location descriptions that have an address space just
+like for any other kind of location description.
+
+![Address Spaces Example: Step 5](images/09-extension-form-aspace.example.frame.5.png)
+
+The only operations in DWARF 5 that take an address space are DW_OP_xderef*.
+They treat a value as the address in a specified address space, and read its
+contents. There is no operation to actually create a location description that
+references an address space. There is no way to include address space memory
+locations in parts of composite locations.
+
+Since DW_OP_piece now takes any kind of location description for its pieces, it
+is now possible for parts of a composite to involve locations in different
+address spaces. For example, this can happen when parts of a source variable
+allocated in a register are spilled to a stack frame that resides in the
+non-global address space.
+
+### 4.3.5 Bit Offsets
+
+With the generalization of location descriptions on the stack, it is possible to
+define a DW_OP_bit_offset operation that adjusts the offset of any kind of
+location in terms of bits rather than bytes. The offset can be a runtime
+computed value. This is generally useful for any source language that support
+bit sized entities, and for registers that are not a whole number of bytes.
+
+DWARF 5 only supports bit fields in composites using DW_OP_bit_piece. It does
+not support runtime computed offsets which can happen for bit field packed
+arrays. It is also not generally composable as it must be the last part of an
+expression.
+
+The following example defines a location description for a source variable that
+is allocated starting at bit 20 of a register. A similar expression could be
+used if the source variable was at a bit offset within memory or a particular
+address space, or if the offset is a runtime value.
+
+![Bit Offsets Example](images/10-extension-bit-offset.example.png)
+
+    DW_OP_regx SGPR3
+    DW_OP_uconst 20
+    DW_OP_bit_offset
+
+![Bit Offsets Example: Step 1](images/10-extension-bit-offset.example.frame.1.png)
+
+![Bit Offsets Example: Step 2](images/10-extension-bit-offset.example.frame.2.png)
+
+![Bit Offsets Example: Step 3](images/10-extension-bit-offset.example.frame.3.png)
+
+The DW_OP_bit_offset operation pops a value and location description from the
+stack. It pushes the location description after updating its offset using the
+value as a bit count.
+
+![Bit Offsets Example: Step 4](images/10-extension-bit-offset.example.frame.4.png)
+
+The ordering of bits within a byte, like byte ordering, is defined by the target
+architecture. A base type could be extended to specify bit ordering in addition
+to byte ordering.
+
+## 4.4 Call Frame Information (CFI)
+
+DWARF defines call frame information (CFI) that can be used to virtually unwind
+the subprogram call stack. This involves determining the location where register
+values have been spilled. DWARF 5 limits these locations to either be registers
+or global memory. As shown in the earlier examples, heterogeneous devices may
+spill registers to parts of other registers, to non-global memory address
+spaces, or even a composite of different location kinds.
+
+Therefore, the extension extends the CFI rules to support any kind of location
+description, and operations to create locations in address spaces.
+
+## 4.5 Objects Not In Byte Aligned Global Memory
+
+DWARF 5 only effectively supports byte aligned memory locations on the stack by
+using a global memory address as a proxy for a memory location description. This
+is a problem for attributes that define DWARF expressions that require the
+location of some source language entity that is not allocated in byte aligned
+global memory.
+
+For example, the DWARF expression of the DW_AT_data_member_location attribute is
+evaluated with an initial stack containing the location of a type instance
+object. That object could be located in a register, in a non-global memory
+address space, be described by a composite location description, or could even
+be an implicit location description.
+
+A similar problem exists for DWARF expressions that use the
+DW_OP_push_object_address operation. This operation pushes the location of a
+program object associated with the attribute that defines the expression.
+
+Allowing any kind of location description on the stack permits the DW_OP_call*
+operations to be used to factor the creation of location descriptions. The
+inputs and outputs of the call are passed on the stack. For example, on GPUs an
+expression can be defined to describe the effective PC of inactive lanes of SIMT
+execution. This is naturally done by composing the result of expressions for
+each nested control flow region. This can be done by making each control flow
+region have its own DWARF procedure, and then calling it from the expressions of
+the nested control flow regions. The alternative is to make each control flow
+region have the complete expression which results in much larger DWARF and is
+less convenient to generate.
+
+GPU compilers work hard to allocate objects in the larger number of registers to
+reduce memory accesses, they have to use different memory address spaces, and
+they perform optimizations that result in composites of these. Allowing
+operations to work with any kind of location description enables creating
+expressions that support all of these.
+
+Full general support for bit fields and implicit locations benefits
+optimizations on any target.
+
+## 4.6 Higher Order Operations
+
+The generalization allows an elegant way to add higher order operations that
+create location descriptions out of other location descriptions in a general
+composable manner.
+
+For example, a DW_OP_extend operation could create a composite location
+description out of a location description, an element size, and an element
+count. The resulting composite would effectively be a vector of element count
+elements with each element being the same location description of the specified
+bit size.
+
+A DW_OP_select_bit_piece operation could create a composite location description
+out of two location descriptions, a bit mask value, and an element size. The
+resulting composite would effectively be a vector of elements, selecting from
+one of the two input locations according to the bit mask.
+
+These could be used in the expression of an attribute that computes the
+effective PC of lanes of SIMT execution. The vector result efficiently computes
+the PC for each SIMT lane at once. The mask could be the hardware execution mask
+register that controls which SIMT lanes are executing. For active divergent
+lanes the vector element would be the current PC, and for inactive divergent
+lanes the PC would correspond to the source language line at which the lane is
+logically positioned.
+
+Similarly, a DW_OP_overlay_piece operation could be defined that creates a
+composite location description out of two location descriptions, an offset
+value, and a size. The resulting composite would consist of parts that are
+equivalent to one of the location descriptions, but with the other location
+description replacing a slice defined by the offset and size. This could be used
+to efficiently express a source language array that has had a set of elements
+promoted into a vector register when executing a set of iterations of a loop in
+a SIMD manner.
+
+## 4.7 Objects In Multiple Places
+
+A compiler may allocate a source variable in stack frame memory, but for some
+range of code may promote it to a register. If the generated code does not
+change the register value, then there is no need to save it back to memory.
+Effectively, during that range, the source variable is in both memory and a
+register. If a consumer, such as a debugger, allows the user to change the value
+of the source variable in that PC range, then it would need to change both
+places.
+
+DWARF 5 supports loclists which are able to specify the location of a source
+language entity is in different places at different PC locations. It can also
+express that a source language entity is in multiple places at the same time.
+
+DWARF 5 defines operation expressions and loclists separately. In general, this
+is adequate as non-memory location descriptions can only be computed as the last
+step of an expression evaluation.
+
+However, allowing location descriptions on the stack permits non-memory location
+descriptions to be used in the middle of expression evaluation. For example, the
+DW_OP_call* and DW_OP_implicit_pointer operations can result in evaluating the
+expression of a DW_AT_location attribute of a DIE. The DW_AT_location attribute
+allows the loclist form. So the result could include multiple location
+descriptions.
+
+Similarly, the DWARF expression associated with attributes such as
+DW_AT_data_member_location that are evaluated with an initial stack containing a
+location description, or a DWARF operation expression that uses the
+DW_OP_push_object_address operation, may want to act on the result of another
+expression that returned a location description involving multiple places.
+
+Therefore, the extension needs to define how expression operations that use those
+results will behave. The extension does this by generalizing the expression stack
+to allow an entry to be one or more single location descriptions. In doing this,
+it unifies the definitions of DWARF operation expressions and loclist
+expressions in a natural way.
+
+All operations that act on location descriptions are extended to act on multiple
+single location descriptions. For example, the DW_OP_offset operation adds the
+offset to each single location description. The DW_OP_deref* operations simply
+read the storage of one of the single location descriptions, since multiple
+single location descriptions must all hold the same value. Similarly, if the
+evaluation of a DWARF expression results in multiple single location
+descriptions, the consumer can ensure any updates are done to all of them, and
+any reads can use any one of them.
+
+# 5. Conclusion
+
+A strength of DWARF is that it has generally sought to provide generalized
+composable solutions that address many problems, rather than solutions that only
+address one-off issues. This extension attempts to follow that tradition by
+defining a backwards compatible composable generalization that can address a
+significant family of issues. It addresses the specific issues present for
+heterogeneous computing devices, provides benefits for non-heterogeneous
+devices, and can help address a number of other previously reported issues.
+
+# A. Changes to DWARF Debugging Information Format Version 5
+
+> NOTE: This appendix provides changes relative to DWARF Version 5. It has been
+> defined such that it is backwards compatible with DWARF Version 5.
+> Non-normative text is shown in <i>italics</i>. The section numbers generally
+> correspond to those in the DWARF Version 5 standard unless specified
+> otherwise. Definitions are given to clarify how existing expression
+> operations, CFI operations, and attributes behave with respect to generalized
+> location descriptions that support multiple places.
+>
+> > NOTE: Notes are included to describe how the changes are to be applied to
+> > the DWARF Version 5 standard. They also describe rational and issues that
+> > may need further consideration.
+
+## A.2 General Description
+
+### A.2.5 DWARF Expressions
+
+> NOTE: This section, and its nested sections, replaces DWARF Version 5 section
+> 2.5 and section 2.6. It is based on the text of the existing DWARF Version 5
+> standard.
+
+DWARF expressions describe how to compute a value or specify a location.
+
+<i>The evaluation of a DWARF expression can provide the location of an object,
+the value of an array bound, the length of a dynamic string, the desired value
+itself, and so on.</i>
+
+If the evaluation of a DWARF expression does not encounter an error, then it can
+either result in a value (see [2.5.2 DWARF Expression
+Value](#dwarf-expression-value)) or a location description (see [2.5.3 DWARF
+Location Description](#dwarf-location-description)). When a DWARF expression
+is evaluated, it may be specified whether a value or location description is
+required as the result kind.
+
+If a result kind is specified, and the result of the evaluation does not match
+the specified result kind, then the implicit conversions described in [2.5.4.4.3
+Memory Location Description
+Operations](#memory-location-description-operations) are performed if
+valid. Otherwise, the DWARF expression is ill-formed.
+
+If the evaluation of a DWARF expression encounters an evaluation error, then the
+result is an evaluation error.
+
+> NOTE: Decided to define the concept of an evaluation error. An alternative is
+> to introduce an undefined value base type in a similar way to location
+> descriptions having an undefined location description. Then operations that
+> encounter an evaluation error can return the undefined location description or
+> value with an undefined base type.
+>
+> All operations that act on values would return an undefined entity if given an
+> undefined value. The expression would then always evaluate to completion, and
+> can be tested to determine if it is an undefined entity.
+>
+> However, this would add considerable additional complexity and does not match
+> that GDB throws an exception when these evaluation errors occur.
+
+If a DWARF expression is ill-formed, then the result is undefined.
+
+The following sections detail the rules for when a DWARF expression is
+ill-formed or results in an evaluation error.
+
+A DWARF expression can either be encoded as an operation expression (see [2.5.4
+DWARF Operation Expressions](#dwarf-operation-expressions)), or as a
+location list expression (see [2.5.5 DWARF Location List
+Expressions](#dwarf-location-list-expressions)).
+
+#### A.2.5.1 DWARF Expression Evaluation Context
+
+A DWARF expression is evaluated in a context that can include a number of
+context elements. If multiple context elements are specified then they must be
+self consistent or the result of the evaluation is undefined. The context
+elements that can be specified are:
+
+1.  <i>A current result kind</i>
+
+    The kind of result required by the DWARF expression evaluation. If specified
+    it can be a location description or a value.
+
+2.  <i>A current thread</i>
+
+    The target architecture thread identifier of the source program thread of
+    execution for which a user presented expression is currently being
+    evaluated.
+
+    It is required for operations that are related to target architecture
+    threads.
+
+    <i>For example, the `DW_OP_regval_type` operation.</i>
+
+3.  <i>A current call frame</i>
+
+    The target architecture call frame identifier. It identifies a call frame
+    that corresponds to an active invocation of a subprogram in the current
+    thread. It is identified by its address on the call stack. The address is
+    referred to as the Canonical Frame Address (CFA). The call frame information
+    is used to determine the CFA for the call frames of the current thread's
+    call stack (see [6.4 Call Frame Information](#call-frame-information)).
+
+    It is required for operations that specify target architecture registers to
+    support virtual unwinding of the call stack.
+
+    <i>For example, the `DW_OP_*reg*` operations.</i>
+
+    If specified, it must be an active call frame in the current thread.
+    Otherwise the result is undefined.
+
+    If it is the currently executing call frame, then it is termed the top call
+    frame.
+
+4.  <i>A current program location</i>
+
+    The target architecture program location corresponding to the current call
+    frame of the current thread.
+
+    The program location of the top call frame is the target architecture
+    program counter for the current thread. The call frame information is used
+    to obtain the value of the return address register to determine the program
+    location of the other call frames (see [6.4 Call Frame
+    Information](#call-frame-information)).
+
+    It is required for the evaluation of location list expressions to select
+    amongst multiple program location ranges. It is required for operations that
+    specify target architecture registers to support virtual unwinding of the
+    call stack (see [6.4 Call Frame Information](#call-frame-information)).
+
+    If specified:
+
+    - If the current call frame is the top call frame, it must be the current
+      target architecture program location.
+    - If the current call frame F is not the top call frame, it must be the
+      program location associated with the call site in the current caller frame
+      F that invoked the callee frame.
+    - Otherwise the result is undefined.
+
+5.  <i>A current compilation unit</i>
+
+    The compilation unit debug information entry that contains the DWARF
+    expression being evaluated.
+
+    It is required for operations that reference debug information associated
+    with the same compilation unit, including indicating if such references use
+    the 32-bit or 64-bit DWARF format. It can also provide the default address
+    space address size if no current target architecture is specified.
+
+    <i>For example, the `DW_OP_constx` and `DW_OP_addrx` operations.</i>
+
+    <i>Note that this compilation unit may not be the same as the compilation
+    unit determined from the loaded code object corresponding to the current
+    program location. For example, the evaluation of the expression E associated
+    with a `DW_AT_location` attribute of the debug information entry operand of
+    the `DW_OP_call*` operations is evaluated with the compilation unit that
+    contains E and not the one that contains the `DW_OP_call*` operation
+    expression.</i>
+
+6.  <i>A current target architecture</i>
+
+    The target architecture.
+
+    It is required for operations that specify target architecture specific
+    entities.
+
+    <i>For example, target architecture specific entities include DWARF register
+    identifiers, DWARF address space identifiers, the default address space, and
+    the address space address sizes.</i>
+
+    If specified:
+
+    - If the current thread is specified, then the current target architecture
+      must be the same as the target architecture of the current thread.
+    - If the current compilation unit is specified, then the current target
+      architecture default address space address size must be the same as the
+      `address_size` field in the header of the current compilation unit and any
+      associated entry in the `.debug_aranges` section.
+    - If the current program location is specified, then the current target
+      architecture must be the same as the target architecture of any line
+      number information entry (see [6.2 Line Number
+      Information](#line-number-information)) corresponding to the current
+      program location.
+    - If the current program location is specified, then the current target
+      architecture default address space address size must be the same as the
+      `address_size` field in the header of any entry corresponding to the
+      current program location in the `.debug_addr`, `.debug_line`,
+      `.debug_rnglists`, `.debug_rnglists.dwo`, `.debug_loclists`, and
+      `.debug_loclists.dwo` sections.
+    - Otherwise the result is undefined.
+
+7.  <i>A current object</i>
+
+    The location description of a program object.
+
+    It is required for the `DW_OP_push_object_address` operation.
+
+    <i>For example, the `DW_AT_data_location` attribute on type debug
+    information entries specifies the program object corresponding to a runtime
+    descriptor as the current object when it evaluates its associated
+    expression.</i>
+
+    The result is undefined if the location descriptor is invalid (see [3.5.3
+    DWARF Location Description](#dwarf-location-description)).
+
+8.  <i>An initial stack</i>
+
+    This is a list of values or location descriptions that will be pushed on the
+    operation expression evaluation stack in the order provided before
+    evaluation of an operation expression starts.
+
+    Some debugger information entries have attributes that evaluate their DWARF
+    expression value with initial stack entries. In all other cases the initial
+    stack is empty.
+
+    The result is undefined if any location descriptors are invalid (see [3.5.3
+    DWARF Location Description](#dwarf-location-description)).
+
+If the evaluation requires a context element that is not specified, then the
+result of the evaluation is an error.
+
+<i>A DWARF expression for a location description may be able to be evaluated
+without a thread, call frame, program location, or architecture context. For
+example, the location of a global variable may be able to be evaluated without
+such context. If the expression evaluates with an error then it may indicate the
+variable has been optimized and so requires more context.</i>
+
+<i>The DWARF expression for call frame information (see [6.4 Call Frame
+Information](#call-frame-information)) operations are restricted to those
+that do not require the compilation unit context to be specified.</i>
+
+The DWARF is ill-formed if all the `address_size` fields in the headers of all
+the entries in the `.debug_info`, `.debug_addr`, `.debug_line`,
+`.debug_rnglists`, `.debug_rnglists.dwo`, `.debug_loclists`, and
+`.debug_loclists.dwo` sections corresponding to any given program location do
+not match.
+
+#### A.2.5.2 DWARF Expression Value
+
+A value has a type and a literal value. It can represent a literal value of any
+supported base type of the target architecture. The base type specifies the
+size, encoding, and endianity of the literal value.
+
+> NOTE: It may be desirable to add an implicit pointer base type encoding. It
+> would be used for the type of the value that is produced when the
+> `DW_OP_deref*` operation retrieves the full contents of an implicit pointer
+> location storage created by the `DW_OP_implicit_pointer` operation. The
+> literal value would record the debugging information entry and byte
+> displacement specified by the associated `DW_OP_implicit_pointer` operation.
+
+There is a distinguished base type termed the generic type, which is an integral
+type that has the size of an address in the target architecture default address
+space, a target architecture defined endianity, and unspecified signedness.
+
+<i>The generic type is the same as the unspecified type used for stack
+operations defined in DWARF Version 4 and before.</i>
+
+An integral type is a base type that has an encoding of `DW_ATE_signed`,
+`DW_ATE_signed_char`, `DW_ATE_unsigned`, `DW_ATE_unsigned_char`,
+`DW_ATE_boolean`, or any target architecture defined integral encoding in the
+inclusive range `DW_ATE_lo_user` to `DW_ATE_hi_user`.
+
+> NOTE: It is unclear if `DW_ATE_address` is an integral type. GDB does not seem
+> to consider it as integral.
+
+#### A.2.5.3 DWARF Location Description
+
+<i>Debugging information must provide consumers a way to find the location of
+program variables, determine the bounds of dynamic arrays and strings, and
+possibly to find the base address of a subprogram's call frame or the return
+address of a subprogram. Furthermore, to meet the needs of recent computer
+architectures and optimization techniques, debugging information must be able to
+describe the location of an object whose location changes over the object's
+lifetime, and may reside at multiple locations simultaneously during parts of an
+object's lifetime.</i>
+
+Information about the location of program objects is provided by location
+descriptions.
+
+Location descriptions can consist of one or more single location descriptions.
+
+A single location description specifies the location storage that holds a
+program object and a position within the location storage where the program
+object starts. The position within the location storage is expressed as a bit
+offset relative to the start of the location storage.
+
+A location storage is a linear stream of bits that can hold values. Each
+location storage has a size in bits and can be accessed using a zero-based bit
+offset. The ordering of bits within a location storage uses the bit numbering
+and direction conventions that are appropriate to the current language on the
+target architecture.
+
+There are five kinds of location storage:
+
+1.  <i>memory location storage</i>
+
+    Corresponds to the target architecture memory address spaces.
+
+2.  <i>register location storage</i>
+
+    Corresponds to the target architecture registers.
+
+3.  <i>implicit location storage</i>
+
+    Corresponds to fixed values that can only be read.
+
+4.  <i>undefined location storage</i>
+
+    Indicates no value is available and therefore cannot be read or written.
+
+5.  <i>composite location storage</i>
+
+    Allows a mixture of these where some bits come from one location storage and
+    some from another location storage, or from disjoint parts of the same
+    location storage.
+
+> NOTE: It may be better to add an implicit pointer location storage kind used
+> by the `DW_OP_implicit_pointer` operation. It would specify the debugger
+> information entry and byte offset provided by the operations.
+
+<i>Location descriptions are a language independent representation of addressing
+rules.</i>
+
+- <i>They can be the result of evaluating a debugger information entry attribute
+  that specifies an operation expression of arbitrary complexity. In this usage
+  they can describe the location of an object as long as its lifetime is either
+  static or the same as the lexical block (see [3.5 Lexical Block
+  Entries](#lexical-block-entries)) that owns it, and it does not move during
+  its lifetime.</i>
+
+- <i>They can be the result of evaluating a debugger information entry attribute
+  that specifies a location list expression. In this usage they can describe the
+  location of an object that has a limited lifetime, changes its location during
+  its lifetime, or has multiple locations over part or all of its lifetime.</i>
+
+If a location description has more than one single location description, the
+DWARF expression is ill-formed if the object value held in each single location
+description's position within the associated location storage is not the same
+value, except for the parts of the value that are uninitialized.
+
+<i>A location description that has more than one single location description can
+only be created by a location list expression that has overlapping program
+location ranges, or certain expression operations that act on a location
+description that has more than one single location description. There are no
+operation expression operations that can directly create a location description
+with more than one single location description.</i>
+
+<i>A location description with more than one single location description can be
+used to describe objects that reside in more than one piece of storage at the
+same time. An object may have more than one location as a result of
+optimization. For example, a value that is only read may be promoted from memory
+to a register for some region of code, but later code may revert to reading the
+value from memory as the register may be used for other purposes. For the code
+region where the value is in a register, any change to the object value must be
+made in both the register and the memory so both regions of code will read the
+updated value.</i>
+
+<i>A consumer of a location description with more than one single location
+description can read the object's value from any of the single location
+descriptions (since they all refer to location storage that has the same value),
+but must write any changed value to all the single location descriptions.</i>
+
+Updating a location description L by a bit offset B is defined as adding the
+value of B to the bit offset of each single location description SL of L. It is
+an evaluation error if the updated bit offset of any SL is less than 0 or
+greater than or equal to the size of the location storage specified by SL.
+
+The evaluation of an expression may require context elements to create a
+location description. If such a location description is accessed, the storage it
+denotes is that associated with the context element values specified when the
+location description was created, which may differ from the context at the time
+it is accessed.
+
+<i>For example, creating a register location description requires the thread
+context: the location storage is for the specified register of that thread.
+Creating a memory location description for an address space may required a
+thread context: the location storage is the memory associated with that
+thread.</i>
+
+If any of the context elements required to create a location description change,
+the location description becomes invalid and accessing it is undefined.
+
+<i>Examples of context that can invalidate a location description are:</i>
+
+- <i>The thread context is required and execution causes the thread to
+  terminate.</i>
+- <i>The call frame context is required and further execution causes the call
+  frame to return to the calling frame.</i>
+- <i>The program location is required and further execution of the thread
+  occurs. That could change the location list entry or call frame information
+  entry that applies.</i>
+- <i>An operation uses call frame information:</i>
+  - <i>Any of the frames used in the virtual call frame unwinding return.</i>
+  - <i>The top call frame is used, the program location is used to select the
+    call frame information entry, and further execution of the thread
+    occurs.</i>
+
+<i>A DWARF expression can be used to compute a location description for an
+object. A subsequent DWARF expression evaluation can be given the object
+location description as the object context or initial stack context to compute a
+component of the object. The final result is undefined if the object location
+description becomes invalid between the two expression evaluations.</i>
+
+A change of a thread's program location may not make a location description
+invalid, yet may still render it as no longer meaningful. Accessing such a
+location description, or using it as the object context or initial stack context
+of an expression evaluation, may produce an undefined result.
+
+<i>For example, a location description may specify a register that no longer
+holds the intended program object after a program location change. One way to
+avoid such problems is to recompute location descriptions associated with
+threads when their program locations change.</i>
+
+#### A.2.5.4 DWARF Operation Expressions
+
+An operation expression is comprised of a stream of operations, each consisting
+of an opcode followed by zero or more operands. The number of operands is
+implied by the opcode.
+
+Operations represent a postfix operation on a simple stack machine. Each stack
+entry can hold either a value or a location description. Operations can act on
+entries on the stack, including adding entries and removing entries. If the kind
+of a stack entry does not match the kind required by the operation and is not
+implicitly convertible to the required kind (see [2.5.4.4.3 Memory Location
+Description Operations](#memory-location-description-operations)), then
+the DWARF operation expression is ill-formed.
+
+Evaluation of an operation expression starts with an empty stack on which the
+entries from the initial stack provided by the context are pushed in the order
+provided. Then the operations are evaluated, starting with the first operation
+of the stream. Evaluation continues until either an operation has an evaluation
+error, or until one past the last operation of the stream is reached.
+
+The result of the evaluation is:
+
+- If an operation has an evaluation error, or an operation evaluates an
+  expression that has an evaluation error, then the result is an evaluation
+  error.
+- If the current result kind specifies a location description, then:
+  - If the stack is empty, the result is a location description with one
+    undefined location description.
+
+    <i>This rule is for backwards compatibility with DWARF Version 5 which uses
+    an empty operation expression for this purpose.</i>
+
+  - If the top stack entry is a location description, or can be converted to one
+    (see [2.5.4.4.3 Memory Location Description
+    Operations](#memory-location-description-operations)), then the result
+    is that, possibly converted, location description. Any other entries on the
+    stack are discarded.
+  - Otherwise the DWARF expression is ill-formed.
+
+    > NOTE: Could define this case as returning an implicit location description
+    > as if the `DW_OP_implicit` operation is performed.
+
+- If the current result kind specifies a value, then:
+  - If the top stack entry is a value, or can be converted to one (see
+    [2.5.4.4.3 Memory Location Description
+    Operations](#memory-location-description-operations)), then the result is
+    that, possibly converted, value. Any other entries on the stack are
+    discarded.
+  - Otherwise the DWARF expression is ill-formed.
+- If the current result kind is not specified, then:
+  - If the stack is empty, the result is a location description with one
+    undefined location description.
+
+    <i>This rule is for backwards compatibility with DWARF Version 5 which uses
+    an empty operation expression for this purpose.</i>
+
+    > NOTE: This rule is consistent with the rule above for when a location
+    > description is requested. However, GDB appears to report this as an error
+    > and no GDB tests appear to cause an empty stack for this case.
+
+  - Otherwise, the top stack entry is returned. Any other entries on the stack
+    are discarded.
+
+An operation expression is encoded as a byte block with some form of prefix that
+specifies the byte count. It can be used:
+
+- as the value of a debugging information entry attribute that is encoded using
+  class `exprloc` (see [7.5.5 Classes and Forms](#classes-and-forms)),
+- as the operand to certain operation expression operations,
+- as the operand to certain call frame information operations (see [6.4 Call
+  Frame Information](#call-frame-information)),
+- and in location list entries (see [2.5.5 DWARF Location List
+  Expressions](#dwarf-location-list-expressions)).
+
+##### A.2.5.4.1 Stack Operations
+
+> NOTE: This section replaces DWARF Version 5 section 2.5.1.3.
+
+The following operations manipulate the DWARF stack. Operations that index the
+stack assume that the top of the stack (most recently added entry) has index 0.
+They allow the stack entries to be either a value or location description.
+
+If any stack entry accessed by a stack operation is an incomplete composite
+location description (see [2.5.4.4.6 Composite Location Description
+Operations](#composite-location-description-operations)), then the DWARF
+expression is ill-formed.
+
+> NOTE: These operations now support stack entries that are values and location
+> descriptions.
+
+> NOTE: If it is desired to also make them work with incomplete composite
+> location descriptions, then would need to define that the composite location
+> storage specified by the incomplete composite location description is also
+> replicated when a copy is pushed. This ensures that each copy of the
+> incomplete composite location description can update the composite location
+> storage they specify independently.
+
+1.  `DW_OP_dup`
+
+    `DW_OP_dup` duplicates the stack entry at the top of the stack.
+
+2.  `DW_OP_drop`
+
+    `DW_OP_drop` pops the stack entry at the top of the stack and discards it.
+
+3.  `DW_OP_pick`
+
+    `DW_OP_pick` has a single unsigned 1-byte operand that represents an index
+    I.  A copy of the stack entry with index I is pushed onto the stack.
+
+4.  `DW_OP_over`
+
+    `DW_OP_over` pushes a copy of the entry with index 1.
+
+    <i>This is equivalent to a `DW_OP_pick 1` operation.</i>
+
+5.  `DW_OP_swap`
+
+    `DW_OP_swap` swaps the top two stack entries. The entry at the top of the
+    stack becomes the second stack entry, and the second stack entry becomes the
+    top of the stack.
+
+6.  `DW_OP_rot`
+
+    `DW_OP_rot` rotates the first three stack entries. The entry at the top of
+    the stack becomes the third stack entry, the second entry becomes the top of
+    the stack, and the third entry becomes the second entry.
+
+##### A.2.5.4.2 Control Flow Operations
+
+> NOTE: This section replaces DWARF Version 5 section 2.5.1.5.
+
+The following operations provide simple control of the flow of a DWARF operation
+expression.
+
+1.  `DW_OP_nop`
+
+    `DW_OP_nop` is a place holder. It has no effect on the DWARF stack entries.
+
+2.  `DW_OP_le`, `DW_OP_ge`, `DW_OP_eq`, `DW_OP_lt`, `DW_OP_gt`,
+    `DW_OP_ne`
+
+    > NOTE: The same as in DWARF Version 5 section 2.5.1.5.
+
+3.  `DW_OP_skip`
+
+    `DW_OP_skip` is an unconditional branch. Its single operand is a 2-byte
+    signed integer constant. The 2-byte constant is the number of bytes of the
+    DWARF expression to skip forward or backward from the current operation,
+    beginning after the 2-byte constant.
+
+    If the updated position is at one past the end of the last operation, then
+    the operation expression evaluation is complete.
+
+    Otherwise, the DWARF expression is ill-formed if the updated operation
+    position is not in the range of the first to last operation inclusive, or
+    not at the start of an operation.
+
+4.  `DW_OP_bra`
+
+    `DW_OP_bra` is a conditional branch. Its single operand is a 2-byte signed
+    integer constant. This operation pops the top of stack. If the value popped
+    is not the constant 0, the 2-byte constant operand is the number of bytes of
+    the DWARF operation expression to skip forward or backward from the current
+    operation, beginning after the 2-byte constant.
+
+    If the updated position is at one past the end of the last operation, then
+    the operation expression evaluation is complete.
+
+    Otherwise, the DWARF expression is ill-formed if the updated operation
+    position is not in the range of the first to last operation inclusive, or
+    not at the start of an operation.
+
+5.  `DW_OP_call2, DW_OP_call4, DW_OP_call_ref`
+
+    `DW_OP_call2`, `DW_OP_call4`, and `DW_OP_call_ref` perform DWARF procedure
+    calls during evaluation of a DWARF expression.
+
+    `DW_OP_call2` and `DW_OP_call4`, have one operand that is, respectively, a
+    2-byte or 4-byte unsigned offset DR that represents the byte offset of a
+    debugging information entry D relative to the beginning of the current
+    compilation unit.
+
+    `DW_OP_call_ref` has one operand that is a 4-byte unsigned value in the
+    32-bit DWARF format, or an 8-byte unsigned value in the 64-bit DWARF format,
+    that represents the byte offset DR of a debugging information entry D
+    relative to the beginning of the `.debug_info` section that contains the
+    current compilation unit. D may not be in the current compilation unit.
+
+    > NOTE: DWARF Version 5 states that DR can be an offset in a `.debug_info`
+    > section other than the one that contains the current compilation unit. It
+    > states that relocation of references from one executable or shared object
+    > file to another must be performed by the consumer. But given that DR is
+    > defined as an offset in a `.debug_info` section this seems impossible. If
+    > DR was defined as an implementation defined value, then the consumer could
+    > choose to interpret the value in an implementation defined manner to
+    > reference a debug information in another executable or shared object.
+    >
+    > In ELF the `.debug_info` section is in a non-`PT_LOAD` segment so standard
+    > dynamic relocations cannot be used. But even if they were loaded segments
+    > and dynamic relocations were used, DR would need to be the address of D,
+    > not an offset in a `.debug_info` section. That would also need DR to be
+    > the size of a global address. So it would not be possible to use the
+    > 32-bit DWARF format in a 64-bit global address space. In addition, the
+    > consumer would need to determine what executable or shared object the
+    > relocated address was in so it could determine the containing compilation
+    > unit.
+    >
+    > GDB only interprets DR as an offset in the `.debug_info` section that
+    > contains the current compilation unit.
+    >
+    > This comment also applies to `DW_OP_implicit_pointer`.
+
+    <i>Operand interpretation of `DW_OP_call2`, `DW_OP_call4`, and
+    `DW_OP_call_ref` is exactly like that for `DW_FORM_ref2`, `DW_FORM_ref4`,
+    and `DW_FORM_ref_addr`, respectively.</i>
+
+    The call operation is evaluated by:
+
+    - If D has a `DW_AT_location` attribute that is encoded as a `exprloc` that
+      specifies an operation expression E, then execution of the current
+      operation expression continues from the first operation of E. Execution
+      continues until one past the last operation of E is reached, at which
+      point execution continues with the operation following the call operation.
+      The operations of E are evaluated with the same current context, except
+      current compilation unit is the one that contains D and the stack is the
+      same as that being used by the call operation. After the call operation
+      has been evaluated, the stack is therefore as it is left by the evaluation
+      of the operations of E. Since E is evaluated on the same stack as the call
+      operation, E can use, and/or remove entries already on the stack, and can
+      add new entries to the stack.
+
+      <i>Values on the stack at the time of the call may be used as parameters
+      by the called expression and values left on the stack by the called
+      expression may be used as return values by prior agreement between the
+      calling and called expressions.</i>
+
+    - If D has a `DW_AT_location` attribute that is encoded as a `loclist` or
+      `loclistsptr`, then the specified location list expression E is evaluated.
+      The evaluation of E uses the current context, except the result kind is a
+      location description, the compilation unit is the one that contains D, and
+      the initial stack is empty. The location description result is pushed on
+      the stack.
+
+      > NOTE: This rule avoids having to define how to execute a matched
+      > location list entry operation expression on the same stack as the call
+      > when there are multiple matches. But it allows the call to obtain the
+      > location description for a variable or formal parameter which may use a
+      > location list expression.
+      >
+      > An alternative is to treat the case when D has a `DW_AT_location`
+      > attribute that is encoded as a `loclist` or `loclistsptr`, and the
+      > specified location list expression E' matches a single location list
+      > entry with operation expression E, the same as the `exprloc` case and
+      > evaluate on the same stack.
+      >
+      > But this is not attractive as if the attribute is for a variable that
+      > happens to end with a non-singleton stack, it will not simply put a
+      > location description on the stack. Presumably the intent of using
+      > `DW_OP_call*` on a variable or formal parameter debugger information
+      > entry is to push just one location description on the stack. That
+      > location description may have more than one single location description.
+      >
+      > The previous rule for `exprloc` also has the same problem, as normally a
+      > variable or formal parameter location expression may leave multiple
+      > entries on the stack and only return the top entry.
+      >
+      > GDB implements `DW_OP_call*` by always executing E on the same stack. If
+      > the location list has multiple matching entries, it simply picks the
+      > first one and ignores the rest. This seems fundamentally at odds with
+      > the desire to support multiple places for variables.
+      >
+      > So, it feels like `DW_OP_call*` should both support pushing a location
+      > description on the stack for a variable or formal parameter, and also
+      > support being able to execute an operation expression on the same stack.
+      > Being able to specify a different operation expression for different
+      > program locations seems a desirable feature to retain.
+      >
+      > A solution to that is to have a distinct `DW_AT_proc` attribute for the
+      > `DW_TAG_dwarf_procedure` debugging information entry. Then the
+      > `DW_AT_location` attribute expression is always executed separately and
+      > pushes a location description (that may have multiple single location
+      > descriptions), and the `DW_AT_proc` attribute expression is always
+      > executed on the same stack and can leave anything on the stack.
+      >
+      > The `DW_AT_proc` attribute could have the new classes `exprproc`,
+      > `loclistproc`, and `loclistsptrproc` to indicate that the expression is
+      > executed on the same stack. `exprproc` is the same encoding as
+      > `exprloc`. `loclistproc` and `loclistsptrproc` are the same encoding as
+      > their non-`proc` counterparts, except the DWARF is ill-formed if the
+      > location list does not match exactly one location list entry and a
+      > default entry is required. These forms indicate explicitly that the
+      > matched single operation expression must be executed on the same stack.
+      > This is better than ad hoc special rules for `loclistproc` and
+      > `loclistsptrproc` which are currently clearly defined to always return a
+      > location description. The producer then explicitly indicates the intent
+      > through the attribute classes.
+      >
+      > Such a change would be a breaking change for how GDB implements
+      > `DW_OP_call*`. However, are the breaking cases actually occurring in
+      > practice? GDB could implement the current approach for DWARF Version 5,
+      > and the new semantics for DWARF Version 6 which has been done for some
+      > other features.
+      >
+      > Another option is to limit the execution to be on the same stack only to
+      > the evaluation of an expression E that is the value of a
+      > `DW_AT_location` attribute of a `DW_TAG_dwarf_procedure` debugging
+      > information entry. The DWARF would be ill-formed if E is a location list
+      > expression that does not match exactly one location list entry. In all
+      > other cases the evaluation of an expression E that is the value of a
+      > `DW_AT_location` attribute would evaluate E with the current context,
+      > except the result kind is a location description, the compilation unit
+      > is the one that contains D, and the initial stack is empty. The location
+      > description result is pushed on the stack.
+
+    - If D has a `DW_AT_const_value` attribute with a value V, then it is as if
+      a `DW_OP_implicit_value V` operation was executed.
+
+      <i>This allows a call operation to be used to compute the location
+      description for any variable or formal parameter regardless of whether the
+      producer has optimized it to a constant. This is consistent with the
+      `DW_OP_implicit_pointer` operation.</i>
+
+      > NOTE: Alternatively, could deprecate using `DW_AT_const_value` for
+      > `DW_TAG_variable` and `DW_TAG_formal_parameter` debugger information
+      > entries that are constants and instead use `DW_AT_location` with an
+      > operation expression that results in a location description with one
+      > implicit location description. Then this rule would not be required.
+
+    - Otherwise, there is no effect and no changes are made to the stack.
+
+      > NOTE: In DWARF Version 5, if D does not have a `DW_AT_location` then
+      > `DW_OP_call*` is defined to have no effect. It is unclear that this is
+      > the right definition as a producer should be able to rely on using
+      > `DW_OP_call*` to get a location description for any
+      > non-`DW_TAG_dwarf_procedure` debugging information entries. Also, the
+      > producer should not be creating DWARF with `DW_OP_call*` to a
+      > `DW_TAG_dwarf_procedure` that does not have a `DW_AT_location`
+      > attribute. So, should this case be defined as an ill-formed DWARF
+      > expression?
+
+    <i>The `DW_TAG_dwarf_procedure` debugging information entry can be used to
+    define DWARF procedures that can be called.</i>
+
+##### A.2.5.4.3 Value Operations
+
+This section describes the operations that push values on the stack.
+
+Each value stack entry has a type and a literal value. It can represent a
+literal value of any supported base type of the target architecture. The base
+type specifies the size, encoding, and endianity of the literal value.
+
+The base type of value stack entries can be the distinguished generic type.
+
+###### A.2.5.4.3.1 Literal Operations
+
+> NOTE: This section replaces DWARF Version 5 section 2.5.1.1.
+
+The following operations all push a literal value onto the DWARF stack.
+
+Operations other than `DW_OP_const_type` push a value V with the generic type.
+If V is larger than the generic type, then V is truncated to the generic type
+size and the low-order bits used.
+
+1.  `DW_OP_lit0`, `DW_OP_lit1`, ..., `DW_OP_lit31`
+
+    `DW_OP_lit<N>` operations encode an unsigned literal value N from 0 through
+    31, inclusive. They push the value N with the generic type.
+
+2.  `DW_OP_const1u`, `DW_OP_const2u`, `DW_OP_const4u`, `DW_OP_const8u`
+
+    `DW_OP_const<N>u` operations have a single operand that is a 1, 2, 4, or
+    8-byte unsigned integer constant U, respectively. They push the value U with
+    the generic type.
+
+3.  `DW_OP_const1s`, `DW_OP_const2s`, `DW_OP_const4s`, `DW_OP_const8s`
+
+    `DW_OP_const<N>s` operations have a single operand that is a 1, 2, 4, or
+    8-byte signed integer constant S, respectively. They push the value S with
+    the generic type.
+
+4.  `DW_OP_constu`
+
+    `DW_OP_constu` has a single unsigned LEB128 integer operand N. It pushes the
+    value N with the generic type.
+
+5.  `DW_OP_consts`
+
+    `DW_OP_consts` has a single signed LEB128 integer operand N. It pushes the
+    value N with the generic type.
+
+6.  `DW_OP_constx`
+
+    `DW_OP_constx` has a single unsigned LEB128 integer operand that represents
+    a zero-based index into the `.debug_addr` section relative to the value of
+    the `DW_AT_addr_base` attribute of the associated compilation unit. The
+    value N in the `.debug_addr` section has the size of the generic type. It
+    pushes the value N with the generic type.
+
+    <i>The `DW_OP_constx` operation is provided for constants that require
+    link-time relocation but should not be interpreted by the consumer as a
+    relocatable address (for example, offsets to thread-local storage).</i>
+
+7.  `DW_OP_const_type`
+
+    `DW_OP_const_type` has three operands. The first is an unsigned LEB128
+    integer DR that represents the byte offset of a debugging information entry
+    D relative to the beginning of the current compilation unit, that provides
+    the type T of the constant value. The second is a 1-byte unsigned integral
+    constant S. The third is a block of bytes B, with a length equal to S.
+
+    TS is the bit size of the type T. The least significant TS bits of B are
+    interpreted as a value V of the type D. It pushes the value V with the type
+    D.
+
+    The DWARF is ill-formed if D is not a `DW_TAG_base_type` debugging
+    information entry in the current compilation unit, or if TS divided by 8
+    (the byte size) and rounded up to a whole number is not equal to S.
+
+    <i>While the size of the byte block B can be inferred from the type D
+    definition, it is encoded explicitly into the operation so that the
+    operation can be parsed easily without reference to the `.debug_info`
+    section.</i>
+
+###### A.2.5.4.3.2 Arithmetic and Logical Operations
+
+> NOTE: This section is the same as DWARF Version 5 section 2.5.1.4.
+
+###### A.2.5.4.3.3 Type Conversion Operations
+
+> NOTE: This section is the same as DWARF Version 5 section 2.5.1.6.
+
+###### A.2.5.4.3.4 Special Value Operations
+
+> NOTE: This section replaces parts of DWARF Version 5 sections 2.5.1.2,
+  2.5.1.3, and 2.5.1.7.
+
+There are these special value operations currently defined:
+
+1.  `DW_OP_regval_type`
+
+    `DW_OP_regval_type` has two operands. The first is an unsigned LEB128
+    integer that represents a register number R. The second is an unsigned
+    LEB128 integer DR that represents the byte offset of a debugging information
+    entry D relative to the beginning of the current compilation unit, that
+    provides the type T of the register value.
+
+    The operation is equivalent to performing `DW_OP_regx R; DW_OP_deref_type
+    DR`.
+
+    > NOTE: Should DWARF allow the type T to be a larger size than the size of
+    > the register R? Restricting a larger bit size avoids any issue of
+    > conversion as the, possibly truncated, bit contents of the register is
+    > simply interpreted as a value of T. If a conversion is wanted it can be
+    > done explicitly using a `DW_OP_convert` operation.
+    >
+    > GDB has a per register hook that allows a target specific conversion on a
+    > register by register basis. It defaults to truncation of bigger registers.
+    > Removing use of the target hook does not cause any test failures in common
+    > architectures. If the compiler for a target architecture did want some
+    > form of conversion, including a larger result type, it could always
+    > explicitly used the `DW_OP_convert` operation.
+    >
+    > If T is a larger type than the register size, then the default GDB
+    > register hook reads bytes from the next register (or reads out of bounds
+    > for the last register!). Removing use of the target hook does not cause
+    > any test failures in common architectures (except an illegal hand written
+    > assembly test). If a target architecture requires this behavior, these
+    > extensions allow a composite location description to be used to combine
+    > multiple registers.
+
+2.  `DW_OP_deref`
+
+    S is the bit size of the generic type divided by 8 (the byte size) and
+    rounded up to a whole number. DR is the offset of a hypothetical debug
+    information entry D in the current compilation unit for a base type of the
+    generic type.
+
+    The operation is equivalent to performing `DW_OP_deref_type S, DR`.
+
+3.  `DW_OP_deref_size`
+
+    `DW_OP_deref_size` has a single 1-byte unsigned integral constant that
+    represents a byte result size S.
+
+    TS is the smaller of the generic type bit size and S scaled by 8 (the byte
+    size). If TS is smaller than the generic type bit size then T is an unsigned
+    integral type of bit size TS, otherwise T is the generic type. DR is the
+    offset of a hypothetical debug information entry D in the current
+    compilation unit for a base type T.
+
+    > NOTE: Truncating the value when S is larger than the generic type matches
+    > what GDB does. This allows the generic type size to not be an integral
+    > byte size. It does allow S to be arbitrarily large. Should S be restricted
+    > to the size of the generic type rounded up to a multiple of 8?
+
+    The operation is equivalent to performing `DW_OP_deref_type S, DR`, except
+    if T is not the generic type, the value V pushed is zero-extended to the
+    generic type bit size and its type changed to the generic type.
+
+4.  `DW_OP_deref_type`
+
+    `DW_OP_deref_type` has two operands. The first is a 1-byte unsigned integral
+    constant S. The second is an unsigned LEB128 integer DR that represents the
+    byte offset of a debugging information entry D relative to the beginning of
+    the current compilation unit, that provides the type T of the result value.
+
+    TS is the bit size of the type T.
+
+    <i>While the size of the pushed value V can be inferred from the type T, it
+    is encoded explicitly as the operand S so that the operation can be parsed
+    easily without reference to the `.debug_info` section.</i>
+
+    > NOTE: It is unclear why the operand S is needed. Unlike
+    > `DW_OP_const_type`, the size is not needed for parsing. Any evaluation
+    > needs to get the base type T to push with the value to know its encoding
+    > and bit size.
+
+    It pops one stack entry that must be a location description L.
+
+    A value V of TS bits is retrieved from the location storage LS specified by
+    one of the single location descriptions SL of L.
+
+    <i>If L, or the location description of any composite location description
+    part that is a subcomponent of L, has more than one single location
+    description, then any one of them can be selected as they are required to
+    all have the same value. For any single location description SL, bits are
+    retrieved from the associated storage location starting at the bit offset
+    specified by SL. For a composite location description, the retrieved bits
+    are the concatenation of the N bits from each composite location part PL,
+    where N is limited to the size of PL.</i>
+
+    V is pushed on the stack with the type T.
+
+    > NOTE: This definition makes it an evaluation error if L is a register
+    > location description that has less than TS bits remaining in the register
+    > storage. Particularly since these extensions extend location descriptions
+    > to have a bit offset, it would be odd to define this as performing sign
+    > extension based on the type, or be target architecture dependent, as the
+    > number of remaining bits could be any number. This matches the GDB
+    > implementation for `DW_OP_deref_type`.
+    >
+    > These extensions define `DW_OP_*breg*` in terms of `DW_OP_regval_type`.
+    > `DW_OP_regval_type` is defined in terms of `DW_OP_regx`, which uses a 0
+    > bit offset, and `DW_OP_deref_type`. Therefore, it requires the register
+    > size to be greater or equal to the address size of the address space. This
+    > matches the GDB implementation for `DW_OP_*breg*`.
+
+    The DWARF is ill-formed if D is not in the current compilation unit, D is
+    not a `DW_TAG_base_type` debugging information entry, or if TS divided by 8
+    (the byte size) and rounded up to a whole number is not equal to S.
+
+    > NOTE: This definition allows the base type to be a bit size since there
+    > seems no reason to restrict it.
+
+    It is an evaluation error if any bit of the value is retrieved from the
+    undefined location storage or the offset of any bit exceeds the size of the
+    location storage LS specified by any single location description SL of L.
+
+    See [2.5.4.4.5 Implicit Location Description
+    Operations](#implicit-location-description-operations) for special
+    rules concerning implicit location descriptions created by the
+    `DW_OP_implicit_pointer` operation.
+
+5.  `DW_OP_xderef`
+
+    `DW_OP_xderef` pops two stack entries. The first must be an integral type
+    value that represents an address A. The second must be an integral type
+    value that represents a target architecture specific address space
+    identifier AS.
+
+    The address size S is defined as the address bit size of the target
+    architecture specific address space that corresponds to AS.
+
+    A is adjusted to S bits by zero extending if necessary, and then treating
+    the least significant S bits as an unsigned value A'.
+
+    It creates a location description L with one memory location description SL.
+    SL specifies the memory location storage LS that corresponds to AS with a
+    bit offset equal to A' scaled by 8 (the byte size).
+
+    If AS is an address space that is specific to context elements, then LS
+    corresponds to the location storage associated with the current context.
+
+    <i>For example, if AS is for per thread storage then LS is the location
+    storage for the current thread. Therefore, if L is accessed by an operation,
+    the location storage selected when the location description was created is
+    accessed, and not the location storage associated with the current context
+    of the access operation.</i>
+
+    The DWARF expression is ill-formed if AS is not one of the values defined by
+    the target architecture specific `DW_ASPACE_*` values.
+
+    The operation is equivalent to popping A and AS, pushing L, and then
+    performing `DW_OP_deref`. The value V retrieved is left on the stack with
+    the generic type.
+
+6.  `DW_OP_xderef_size`
+
+    `DW_OP_xderef_size` has a single 1-byte unsigned integral constant that
+    represents a byte result size S.
+
+    It pops two stack entries. The first must be an integral type value
+    that represents an address A. The second must be an integral type
+    value that represents a target architecture specific address space
+    identifier AS.
+
+    It creates a location description L as described for `DW_OP_xderef`.
+
+    The operation is equivalent to popping A and AS, pushing L, and then
+    performing `DW_OP_deref_size S` . The zero-extended value V retrieved is
+    left on the stack with the generic type.
+
+7.  `DW_OP_xderef_type`
+
+    `DW_OP_xderef_type` has two operands. The first is a 1-byte unsigned
+    integral constant S. The second operand is an unsigned LEB128 integer DR
+    that represents the byte offset of a debugging information entry D relative
+    to the beginning of the current compilation unit, that provides the type T
+    of the result value.
+
+    It pops two stack entries. The first must be an integral type value that
+    represents an address A. The second must be an integral type value that
+    represents a target architecture specific address space identifier AS.
+
+    It creates a location description L as described for `DW_OP_xderef`.
+
+    The operation is equivalent to popping A and AS, pushing L, and then
+    performing `DW_OP_deref_type DR` . The value V retrieved is left on the
+    stack with the type T.
+
+8.  `DW_OP_entry_value` <i>Deprecated</i>
+
+    `DW_OP_entry_value` pushes the value of an expression that is evaluated in
+    the context of the calling frame.
+
+    <i>It may be used to determine the value of arguments on entry to the
+    current call frame provided they are not clobbered.</i>
+
+    It has two operands. The first is an unsigned LEB128 integer S. The second
+    is a block of bytes, with a length equal S, interpreted as a DWARF operation
+    expression E.
+
+    E is evaluated with the current context, except the result kind is
+    unspecified, the call frame is the one that called the current frame, the
+    program location is the call site in the calling frame, the object is
+    unspecified, and the initial stack is empty. The calling frame information
+    is obtained by virtually unwinding the current call frame using the call
+    frame information (see [6.4 Call Frame
+    Information](#call-frame-information)).
+
+    If the result of E is a location description L (see [2.5.4.4.4 Register
+    Location Description
+    Operations](#register-location-description-operations)), and the last
+    operation executed by E is a `DW_OP_reg*` for register R with a target
+    architecture specific base type of T, then the contents of the register are
+    retrieved as if a `DW_OP_deref_type DR` operation was performed where DR is
+    the offset of a hypothetical debug information entry in the current
+    compilation unit for T. The resulting value V s pushed on the stack.
+
+    <i>Using `DW_OP_reg*` provides a more compact form for the case where the
+    value was in a register on entry to the subprogram.</i>
+
+    > NOTE: It is unclear how this provides a more compact expression, as
+    > `DW_OP_regval_type` could be used which is marginally larger.
+
+    If the result of E is a value V, then V is pushed on the stack.
+
+    Otherwise, the DWARF expression is ill-formed.
+
+    <i>The `DW_OP_entry_value` operation is deprecated as its main usage is
+    provided by other means. DWARF Version 5 added the
+    `DW_TAG_call_site_parameter` debugger information entry for call sites that
+    has `DW_AT_call_value`, `DW_AT_call_data_location`, and
+    `DW_AT_call_data_value` attributes that provide DWARF expressions to compute
+    actual parameter values at the time of the call, and requires the producer
+    to ensure the expressions are valid to evaluate even when virtually
+    unwound.</i>
+
+    > NOTE: GDB only implements `DW_OP_entry_value` when E is exactly
+    > `DW_OP_reg*` or `DW_OP_breg*; DW_OP_deref*`.
+
+##### A.2.5.4.4 Location Description Operations
+
+This section describes the operations that push location descriptions on the
+stack.
+
+###### A.2.5.4.4.1 General Location Description Operations
+
+> NOTE: This section replaces part of DWARF Version 5 section 2.5.1.3.
+
+1.  `DW_OP_push_object_address`
+
+    `DW_OP_push_object_address` pushes the location description L of the current
+    object.
+
+    <i>This object may correspond to an independent variable that is part of a
+    user presented expression that is being evaluated. The object location
+    description may be determined from the variable's own debugging information
+    entry or it may be a component of an array, structure, or class whose
+    address has been dynamically determined by an earlier step during user
+    expression evaluation.</i>
+
+    <i>This operation provides explicit functionality (especially for arrays
+    involving descriptors) that is analogous to the implicit push of the base
+    location description of a structure prior to evaluation of a
+    `DW_AT_data_member_location` to access a data member of a structure.</i>
+
+    > NOTE: This operation could be removed and the object location description
+    > specified as the initial stack as for `DW_AT_data_member_location`.
+    >
+    > Or this operation could be used instead of needing to specify an initial
+    > stack. The latter approach is more composable as access to the object may
+    > be needed at any point of the expression, and passing it as the initial
+    > stack requires the entire expression to be aware where on the stack it is.
+    > If this were done, ``DW_AT_use_location`` would require a
+    > ``DW_OP_push_object2_address`` operation for the second object.
+    >
+    > Or a more general way to pass an arbitrary number of arguments in and an
+    > operation to get the Nth one such as ``DW_OP_arg N``. A vector of
+    > arguments would then be passed in the expression context rather than an
+    > initial stack. This could also resolve the issues with ``DW_OP_call*`` by
+    > allowing a specific number of arguments passed in and returned to be
+    > specified. The ``DW_OP_call*`` operation could then always execute on a
+    > separate stack: the number of arguments would be specified in a new call
+    > operation and taken from the callers stack, and similarly the number of
+    > return results specified and copied from the called stack back to the
+    > callee stack when the called expression was complete.
+    >
+    > The only attribute that specifies a current object is
+    > `DW_AT_data_location` so the non-normative text seems to overstate how
+    > this is being used. Or are there other attributes that need to state they
+    > pass an object?
+
+###### A.2.5.4.4.2 Undefined Location Description Operations
+
+> NOTE: This section replaces DWARF Version 5 section 2.6.1.1.1.
+
+<i>The undefined location storage represents a piece or all of an object that is
+present in the source but not in the object code (perhaps due to optimization).
+Neither reading nor writing to the undefined location storage is meaningful.</i>
+
+An undefined location description specifies the undefined location storage.
+There is no concept of the size of the undefined location storage, nor of a bit
+offset for an undefined location description. The `DW_OP_*piece` operations can
+implicitly specify an undefined location description, allowing any size and
+offset to be specified, and results in a part with all undefined bits.
+
+###### A.2.5.4.4.3 Memory Location Description Operations
+
+> NOTE: This section replaces parts of DWARF Version 5 section 2.5.1.1, 2.5.1.2,
+> 2.5.1.3, and 2.6.1.1.2.
+
+Each of the target architecture specific address spaces has a corresponding
+memory location storage that denotes the linear addressable memory of that
+address space. The size of each memory location storage corresponds to the range
+of the addresses in the corresponding address space.
+
+<i>It is target architecture defined how address space location storage maps to
+target architecture physical memory. For example, they may be independent
+memory, or more than one location storage may alias the same physical memory
+possibly at different offsets and with different interleaving. The mapping may
+also be dictated by the source language address classes.</i>
+
+A memory location description specifies a memory location storage. The bit
+offset corresponds to a bit position within a byte of the memory. Bits accessed
+using a memory location description, access the corresponding target
+architecture memory starting at the bit position within the byte specified by
+the bit offset.
+
+A memory location description that has a bit offset that is a multiple of 8 (the
+byte size) is defined to be a byte address memory location description. It has a
+memory byte address A that is equal to the bit offset divided by 8.
+
+A memory location description that does not have a bit offset that is a multiple
+of 8 (the byte size) is defined to be a bit field memory location description.
+It has a bit position B equal to the bit offset modulo 8, and a memory byte
+address A equal to the bit offset minus B that is then divided by 8.
+
+The address space AS of a memory location description is defined to be the
+address space that corresponds to the memory location storage associated with
+the memory location description.
+
+A location description that is comprised of one byte address memory location
+description SL is defined to be a memory byte address location description. It
+has a byte address equal to A and an address space equal to AS of the
+corresponding SL.
+
+`DW_ASPACE_none` is defined as the target architecture default address space.
+
+If a stack entry is required to be a location description, but it is a value V
+with the generic type, then it is implicitly converted to a location description
+L with one memory location description SL. SL specifies the memory location
+storage that corresponds to the target architecture default address space with a
+bit offset equal to V scaled by 8 (the byte size).
+
+> NOTE: If it is wanted to allow any integral type value to be implicitly
+> converted to a memory location description in the target architecture default
+> address space:
+>
+> > If a stack entry is required to be a location description, but is a value V
+> > with an integral type, then it is implicitly converted to a location
+> > description L with a one memory location description SL. If the type size of
+> > V is less than the generic type size, then the value V is zero extended to
+> > the size of the generic type. The least significant generic type size bits
+> > are treated as an unsigned value to be used as an address A. SL specifies
+> > memory location storage corresponding to the target architecture default
+> > address space with a bit offset equal to A scaled by 8 (the byte size).
+>
+> The implicit conversion could also be defined as target architecture specific.
+> For example, GDB checks if V is an integral type. If it is not it gives an
+> error. Otherwise, GDB zero-extends V to 64 bits. If the GDB target defines a
+> hook function, then it is called. The target specific hook function can modify
+> the 64-bit value, possibly sign extending based on the original value type.
+> Finally, GDB treats the 64-bit value V as a memory location address.
+
+If a stack entry is required to be a location description, but it is an implicit
+pointer value IPV with the target architecture default address space, then it is
+implicitly converted to a location description with one single location
+description specified by IPV. See [2.5.4.4.5 Implicit Location Description
+Operations](#implicit-location-description-operations).
+
+If a stack entry is required to be a value, but it is a location description L
+with one memory location description SL in the target architecture default
+address space with a bit offset B that is a multiple of 8, then it is implicitly
+converted to a value equal to B divided by 8 (the byte size) with the generic
+type.
+
+1.  `DW_OP_addr`
+
+    `DW_OP_addr` has a single byte constant value operand, which has the size of
+    the generic type, that represents an address A.
+
+    It pushes a location description L with one memory location description SL
+    on the stack. SL specifies the memory location storage corresponding to the
+    target architecture default address space with a bit offset equal to A
+    scaled by 8 (the byte size).
+
+    <i>If the DWARF is part of a code object, then A may need to be relocated.
+    For example, in the ELF code object format, A must be adjusted by the
+    difference between the ELF segment virtual address and the virtual address
+    at which the segment is loaded.</i>
+
+2.  `DW_OP_addrx`
+
+    `DW_OP_addrx` has a single unsigned LEB128 integer operand that represents a
+    zero-based index into the `.debug_addr` section relative to the value of the
+    `DW_AT_addr_base` attribute of the associated compilation unit. The address
+    value A in the `.debug_addr` section has the size of the generic type.
+
+    It pushes a location description L with one memory location description SL
+    on the stack. SL specifies the memory location storage corresponding to the
+    target architecture default address space with a bit offset equal to A
+    scaled by 8 (the byte size).
+
+    <i>If the DWARF is part of a code object, then A may need to be relocated.
+    For example, in the ELF code object format, A must be adjusted by the
+    difference between the ELF segment virtual address and the virtual address
+    at which the segment is loaded.</i>
+
+3.  `DW_OP_form_tls_address`
+
+    `DW_OP_form_tls_address` pops one stack entry that must be an integral type
+    value and treats it as a thread-local storage address TA.
+
+    It pushes a location description L with one memory location description SL
+    on the stack. SL is the target architecture specific memory location
+    description that corresponds to the thread-local storage address TA.
+
+    The meaning of the thread-local storage address TA is defined by the
+    run-time environment. If the run-time environment supports multiple
+    thread-local storage blocks for a single thread, then the block
+    corresponding to the executable or shared library containing this DWARF
+    expression is used.
+
+    <i>Some implementations of C, C++, Fortran, and other languages support a
+    thread-local storage class. Variables with this storage class have distinct
+    values and addresses in distinct threads, much as automatic variables have
+    distinct values and addresses in each subprogram invocation. Typically,
+    there is a single block of storage containing all thread-local variables
+    declared in the main executable, and a separate block for the variables
+    declared in each shared library. Each thread-local variable can then be
+    accessed in its block using an identifier. This identifier is typically a
+    byte offset into the block and pushed onto the DWARF stack by one of the
+    `DW_OP_const*` operations prior to the `DW_OP_form_tls_address` operation.
+    Computing the address of the appropriate block can be complex (in some
+    cases, the compiler emits a function call to do it), and difficult to
+    describe using ordinary DWARF location descriptions. Instead of forcing
+    complex thread-local storage calculations into the DWARF expressions, the
+    `DW_OP_form_tls_address` allows the consumer to perform the computation
+    based on the target architecture specific run-time environment.</i>
+
+4.  `DW_OP_call_frame_cfa`
+
+    `DW_OP_call_frame_cfa` pushes the location description L of the Canonical
+    Frame Address (CFA) of the current subprogram, obtained from the call frame
+    information on the stack. See [6.4 Call Frame
+    Information](#call-frame-information).
+
+    <i>Although the value of the `DW_AT_frame_base` attribute of the debugger
+    information entry corresponding to the current subprogram can be computed
+    using a location list expression, in some cases this would require an
+    extensive location list because the values of the registers used in
+    computing the CFA change during a subprogram execution. If the call frame
+    information is present, then it already encodes such changes, and it is
+    space efficient to reference that using the `DW_OP_call_frame_cfa`
+    operation.</i>
+
+5.  `DW_OP_fbreg`
+
+    `DW_OP_fbreg` has a single signed LEB128 integer operand that represents a
+    byte displacement B.
+
+    The location description L for the <i>frame base</i> of the current
+    subprogram is obtained from the `DW_AT_frame_base` attribute of the debugger
+    information entry corresponding to the current subprogram as described in
+    [3.3.5 Low-Level Information](#low-level-information).
+
+    The location description L is updated by bit offset B scaled by 8 (the byte
+    size) and pushed on the stack.
+
+6.  `DW_OP_breg0`, `DW_OP_breg1`, ..., `DW_OP_breg31`
+
+    The `DW_OP_breg<N>` operations encode the numbers of up to 32 registers,
+    numbered from 0 through 31, inclusive. The register number R corresponds to
+    the N in the operation name.
+
+    They have a single signed LEB128 integer operand that represents a byte
+    displacement B.
+
+    The address space identifier AS is defined as the one corresponding to the
+    target architecture specific default address space.
+
+    The address size S is defined as the address bit size of the target
+    architecture specific address space corresponding to AS.
+
+    The contents of the register specified by R are retrieved as if a
+    `DW_OP_regval_type R, DR` operation was performed where DR is the offset of
+    a hypothetical debug information entry in the current compilation unit for
+    an unsigned integral base type of size S bits. B is added and the least
+    significant S bits are treated as an unsigned value to be used as an address
+    A.
+
+    They push a location description L comprising one memory location
+    description LS on the stack. LS specifies the memory location storage that
+    corresponds to AS with a bit offset equal to A scaled by 8 (the byte size).
+
+7.  `DW_OP_bregx`
+
+    `DW_OP_bregx` has two operands. The first is an unsigned LEB128 integer that
+    represents a register number R. The second is a signed LEB128 integer that
+    represents a byte displacement B.
+
+    The action is the same as for `DW_OP_breg<N>`, except that R is used as the
+    register number and B is used as the byte displacement.
+
+###### A.2.5.4.4.4 Register Location Description Operations
+
+> NOTE: This section replaces DWARF Version 5 section 2.6.1.1.3.
+
+There is a register location storage that corresponds to each of the target
+architecture registers. The size of each register location storage corresponds
+to the size of the corresponding target architecture register.
+
+A register location description specifies a register location storage. The bit
+offset corresponds to a bit position within the register. Bits accessed using a
+register location description access the corresponding target architecture
+register starting at the specified bit offset.
+
+1.  `DW_OP_reg0`, `DW_OP_reg1`, ..., `DW_OP_reg31`
+
+    `DW_OP_reg<N>` operations encode the numbers of up to 32 registers, numbered
+    from 0 through 31, inclusive. The target architecture register number R
+    corresponds to the N in the operation name.
+
+    The operation is equivalent to performing `DW_OP_regx R`.
+
+2.  `DW_OP_regx`
+
+    `DW_OP_regx` has a single unsigned LEB128 integer operand that represents a
+    target architecture register number R.
+
+    If the current call frame is the top call frame, it pushes a location
+    description L that specifies one register location description SL on the
+    stack. SL specifies the register location storage that corresponds to R with
+    a bit offset of 0 for the current thread.
+
+    If the current call frame is not the top call frame, call frame information
+    (see [6.4 Call Frame Information](#call-frame-information)) is used to
+    determine the location description that holds the register for the current
+    call frame and current program location of the current thread. The resulting
+    location description L is pushed.
+
+    <i>Note that if call frame information is used, the resulting location
+    description may be register, memory, or undefined.</i>
+
+    <i>An implementation may evaluate the call frame information immediately, or
+    may defer evaluation until L is accessed by an operation. If evaluation is
+    deferred, R and the current context can be recorded in L. When accessed, the
+    recorded context is used to evaluate the call frame information, not the
+    current context of the access operation.</i>
+
+<i>These operations obtain a register location. To fetch the contents of a
+register, it is necessary to use `DW_OP_regval_type`, use one of the
+`DW_OP_breg*` register-based addressing operations, or use `DW_OP_deref*` on a
+register location description.</i>
+
+###### A.2.5.4.4.5 Implicit Location Description Operations
+
+> NOTE: This section replaces DWARF Version 5 section 2.6.1.1.4.
+
+Implicit location storage represents a piece or all of an object which has no
+actual location in the program but whose contents are nonetheless known, either
+as a constant or can be computed from other locations and values in the program.
+
+An implicit location description specifies an implicit location storage. The bit
+offset corresponds to a bit position within the implicit location storage. Bits
+accessed using an implicit location description, access the corresponding
+implicit storage value starting at the bit offset.
+
+1.  `DW_OP_implicit_value`
+
+    `DW_OP_implicit_value` has two operands. The first is an unsigned LEB128
+    integer that represents a byte size S. The second is a block of bytes with a
+    length equal to S treated as a literal value V.
+
+    An implicit location storage LS is created with the literal value V and a
+    size of S.
+
+    It pushes location description L with one implicit location description SL
+    on the stack. SL specifies LS with a bit offset of 0.
+
+2.  `DW_OP_stack_value`
+
+    `DW_OP_stack_value` pops one stack entry that must be a value V.
+
+    An implicit location storage LS is created with the literal value V using
+    the size, encoding, and enianity specified by V's base type.
+
+    It pushes a location description L with one implicit location description SL
+    on the stack. SL specifies LS with a bit offset of 0.
+
+    <i>The `DW_OP_stack_value` operation specifies that the object does not
+    exist in memory, but its value is nonetheless known. In this form, the
+    location description specifies the actual value of the object, rather than
+    specifying the memory or register storage that holds the value.</i>
+
+    See [2.5.4.4.5 Implicit Location Description
+    Operations](#implicit-location-description-operations) for special
+    rules concerning implicit pointer values produced by dereferencing implicit
+    location descriptions created by the `DW_OP_implicit_pointer` operation.
+
+    > NOTE: Since location descriptions are allowed on the stack, the
+    > `DW_OP_stack_value` operation no longer terminates the DWARF operation
+    > expression execution as in DWARF Version 5.
+
+3.  `DW_OP_implicit_pointer`
+
+    <i>An optimizing compiler may eliminate a pointer, while still retaining the
+    value that the pointer addressed. `DW_OP_implicit_pointer` allows a producer
+    to describe this value.</i>
+
+    <i>`DW_OP_implicit_pointer` specifies an object is a pointer to the target
+    architecture default address space that cannot be represented as a real
+    pointer, even though the value it would point to can be described. In this
+    form, the location description specifies a debugging information entry that
+    represents the actual location description of the object to which the
+    pointer would point. Thus, a consumer of the debug information would be able
+    to access the dereferenced pointer, even when it cannot access the pointer
+    itself.</i>
+
+    `DW_OP_implicit_pointer` has two operands. The first operand is a 4-byte
+    unsigned value in the 32-bit DWARF format, or an 8-byte unsigned value in
+    the 64-bit DWARF format, that represents the byte offset DR of a debugging
+    information entry D relative to the beginning of the `.debug_info` section
+    that contains the current compilation unit. The second operand is a signed
+    LEB128 integer that represents a byte displacement B.
+
+    <i>Note that D may not be in the current compilation unit.</i>
+
+    <i>The first operand interpretation is exactly like that for
+    `DW_FORM_ref_addr`.</i>
+
+    The address space identifier AS is defined as the one corresponding to the
+    target architecture specific default address space.
+
+    The address size S is defined as the address bit size of the target
+    architecture specific address space corresponding to AS.
+
+    An implicit location storage LS is created with the debugging information
+    entry D, address space AS, and size of S.
+
+    It pushes a location description L that comprises one implicit location
+    description SL on the stack. SL specifies LS with a bit offset of 0.
+
+    It is an evaluation error if a `DW_OP_deref*` operation pops a location
+    description L', and retrieves S bits, such that any retrieved bits come from
+    an implicit location storage that is the same as LS, unless both the
+    following conditions are met:
+
+    1.  All retrieved bits come from an implicit location description that
+        refers to an implicit location storage that is the same as LS.
+
+        <i>Note that all bits do not have to come from the same implicit
+        location description, as L' may involve composite location
+        descriptors.</i>
+
+    2.  The bits come from consecutive ascending offsets within their respective
+        implicit location storage.
+
+    <i>These rules are equivalent to retrieving the complete contents of LS.</i>
+
+    If both the above conditions are met, then the value V pushed by the
+    `DW_OP_deref*` operation is an implicit pointer value IPV with a target
+    architecture specific address space of AS, a debugging information entry of
+    D, and a base type of T. If AS is the target architecture default address
+    space, then T is the generic type. Otherwise, T is a target architecture
+    specific integral type with a bit size equal to S.
+
+    If IPV is either implicitly converted to a location description (only done
+    if AS is the target architecture default address space), then the resulting
+    location description RL is:
+
+    - If D has a `DW_AT_location` attribute, the DWARF expression E from the
+      `DW_AT_location` attribute is evaluated with the current context, except
+      that the result kind is a location description, the compilation unit is
+      the one that contains D, the object is unspecified, and the initial stack
+      is empty. RL is the expression result.
+
+      <i>Note that E is evaluated with the context of the expression accessing
+      IPV, and not the context of the expression that contained the
+      `DW_OP_implicit_pointer` operation that created L.</i>
+
+    - If D has a `DW_AT_const_value` attribute, then an implicit location
+      storage RLS is created from the `DW_AT_const_value` attribute's value with
+      a size matching the size of the `DW_AT_const_value` attribute's value. RL
+      comprises one implicit location description SRL. SRL specifies RLS with a
+      bit offset of 0.
+
+      > NOTE: If using `DW_AT_const_value` for variables and formal parameters
+      > is deprecated and instead `DW_AT_location` is used with an implicit
+      > location description, then this rule would not be required.
+
+    - Otherwise, it is an evaluation error.
+
+    The location description RL is updated by bit offset B scaled by 8 (the byte
+    size).
+
+    If a `DW_OP_stack_value` operation pops a value that is the same as IPV,
+    then it pushes a location description that is the same as L.
+
+    It is an evaluation error if LS or IPV is accessed in any other manner.
+
+    <i>The restrictions on how an implicit pointer location description created
+    by `DW_OP_implicit_pointer` can be used are to simplify the DWARF consumer.
+    Similarly, for an implicit pointer value created by `DW_OP_deref*` and
+    `DW_OP_stack_value`.</i>
+
+<i>Typically a `DW_OP_implicit_pointer` operation is used in a DWARF expression
+E<sub>1</sub> of a `DW_TAG_variable` or `DW_TAG_formal_parameter` debugging
+information entry D<sub>1</sub>'s `DW_AT_location` attribute. The debugging
+information entry referenced by the `DW_OP_implicit_pointer` operation is
+typically itself a `DW_TAG_variable` or `DW_TAG_formal_parameter` debugging
+information entry D<sub>2</sub> whose `DW_AT_location` attribute gives a second
+DWARF expression E<sub>2</sub>.</i>
+
+<i>D<sub>1</sub> and E<sub>1</sub> are describing the location of a pointer type
+object. D<sub>2</sub> and E<sub>2</sub> are describing the location of the
+object pointed to by that pointer object.</i>
+
+<i>However, D<sub>2</sub> may be any debugging information entry that contains a
+`DW_AT_location` or `DW_AT_const_value` attribute (for example,
+`DW_TAG_dwarf_procedure`). By using E<sub>2</sub>, a consumer can reconstruct
+the value of the object when asked to dereference the pointer described by
+E<sub>1</sub> which contains the `DW_OP_implicit_pointer` operation.</i>
+
+###### A.2.5.4.4.6 Composite Location Description Operations
+
+> NOTE: This section replaces DWARF Version 5 section 2.6.1.2.
+
+A composite location storage represents an object or value which may be
+contained in part of another location storage or contained in parts of more than
+one location storage.
+
+Each part has a part location description L and a part bit size S. L can have
+one or more single location descriptions SL. If there are more than one SL then
+that indicates that part is located in more than one place. The bits of each
+place of the part comprise S contiguous bits from the location storage LS
+specified by SL starting at the bit offset specified by SL. All the bits must be
+within the size of LS or the DWARF expression is ill-formed.
+
+A composite location storage can have zero or more parts. The parts are
+contiguous such that the zero-based location storage bit index will range over
+each part with no gaps between them. Therefore, the size of a composite location
+storage is the sum of the size of its parts. The DWARF expression is ill-formed
+if the size of the contiguous location storage is larger than the size of the
+memory location storage corresponding to the largest target architecture
+specific address space.
+
+A composite location description specifies a composite location storage. The bit
+offset corresponds to a bit position within the composite location storage.
+
+There are operations that create a composite location storage.
+
+There are other operations that allow a composite location storage to be
+incrementally created. Each part is created by a separate operation. There may
+be one or more operations to create the final composite location storage. A
+series of such operations describes the parts of the composite location storage
+that are in the order that the associated part operations are executed.
+
+To support incremental creation, a composite location storage can be in an
+incomplete state. When an incremental operation operates on an incomplete
+composite location storage, it adds a new part.
+
+A composite location description that specifies a composite location storage
+that is incomplete is termed an incomplete composite location description. A
+composite location description that specifies a composite location storage that
+is complete is termed a complete composite location description.
+
+If the top stack entry is a location description that has one incomplete
+composite location description SL after the execution of an operation expression
+has completed, SL is converted to a complete composite location description.
+
+<i>Note that this conversion does not happen after the completion of an
+operation expression that is evaluated on the same stack by the `DW_OP_call*`
+operations. Such executions are not a separate evaluation of an operation
+expression, but rather the continued evaluation of the same operation expression
+that contains the `DW_OP_call*` operation.</i>
+
+If a stack entry is required to be a location description L, but L has an
+incomplete composite location description, then the DWARF expression is
+ill-formed. The exception is for the operations involved in incrementally
+creating a composite location description as described below.
+
+<i>Note that a DWARF operation expression may arbitrarily compose composite
+location descriptions from any other location description, including those that
+have multiple single location descriptions, and those that have composite
+location descriptions.</i>
+
+<i>The incremental composite location description operations are defined to be
+compatible with the definitions in DWARF Version 5.</i>
+
+1.  `DW_OP_piece`
+
+    `DW_OP_piece` has a single unsigned LEB128 integer that represents a byte
+    size S.
+
+    The action is based on the context:
+
+    - If the stack is empty, then a location description L comprised of one
+      incomplete composite location description SL is pushed on the stack.
+
+      An incomplete composite location storage LS is created with a single part
+      P. P specifies a location description PL and has a bit size of S scaled by
+      8 (the byte size). PL is comprised of one undefined location description
+      PSL.
+
+      SL specifies LS with a bit offset of 0.
+
+    - Otherwise, if the top stack entry is a location description L comprised of
+      one incomplete composite location description SL, then the incomplete
+      composite location storage LS that SL specifies is updated to append a new
+      part P. P specifies a location description PL and has a bit size of S
+      scaled by 8 (the byte size). PL is comprised of one undefined location
+      description PSL. L is left on the stack.
+    - Otherwise, if the top stack entry is a location description or can be
+      converted to one, then it is popped and treated as a part location
+      description PL. Then:
+
+      - If the top stack entry (after popping PL) is a location description L
+        comprised of one incomplete composite location description SL, then the
+        incomplete composite location storage LS that SL specifies is updated to
+        append a new part P. P specifies the location description PL and has a
+        bit size of S scaled by 8 (the byte size). L is left on the stack.
+      - Otherwise, a location description L comprised of one
+        incomplete composite location description SL is pushed on
+        the stack.
+
+        An incomplete composite location storage LS is created with a single
+        part P. P specifies the location description PL and has a bit size of S
+        scaled by 8 (the byte size).
+
+        SL specifies LS with a bit offset of 0.
+
+    - Otherwise, the DWARF expression is ill-formed
+
+    <i>Many compilers store a single variable in sets of registers or store a
+    variable partially in memory and partially in registers. `DW_OP_piece`
+    provides a way of describing where a part of a variable is located.</i>
+
+    <i>The evaluation rules for the `DW_OP_piece` operation allow it to be
+    compatible with the DWARF Version 5 definition.</i>
+
+    > NOTE: Since these extensions allow location descriptions to be entries on
+    > the stack, a simpler operation to create composite location descriptions
+    > could be defined. For example, just one operation that specifies how many
+    > parts, and pops pairs of stack entries for the part size and location
+    > description. Not only would this be a simpler operation and avoid the
+    > complexities of incomplete composite location descriptions, but it may
+    > also have a smaller encoding in practice. However, the desire for
+    > compatibility with DWARF Version 5 is likely a stronger consideration.
+
+2.  `DW_OP_bit_piece`
+
+    `DW_OP_bit_piece` has two operands. The first is an unsigned LEB128 integer
+    that represents the part bit size S. The second is an unsigned LEB128
+    integer that represents a bit displacement B.
+
+    The action is the same as for `DW_OP_piece`, except that any part created
+    has the bit size S, and the location description PL of any created part is
+    updated by a bit offset B.
+
+    <i>`DW_OP_bit_piece` is used instead of `DW_OP_piece` when the piece to be
+    assembled is not byte-sized or is not at the start of the part location
+    description.</i>
+
+#### A.2.5.5 DWARF Location List Expressions
+
+> NOTE: This section replaces DWARF Version 5 section 2.6.2.
+
+<i>To meet the needs of recent computer architectures and optimization
+techniques, debugging information must be able to describe the location of an
+object whose location changes over the object's lifetime, and may reside at
+multiple locations during parts of an object's lifetime. Location list
+expressions are used in place of operation expressions whenever the object whose
+location is being described has these requirements.</i>
+
+A location list expression consists of a series of location list entries. Each
+location list entry is one of the following kinds:
+
+1.  <i>Bounded location description</i>
+
+    This kind of location list entry provides an operation expression that
+    evaluates to the location description of an object that is valid over a
+    lifetime bounded by a starting and ending address. The starting address is
+    the lowest address of the address range over which the location is valid.
+    The ending address is the address of the first location past the highest
+    address of the address range.
+
+    The location list entry matches when the current program location is within
+    the given range.
+
+    There are several kinds of bounded location description entries which differ
+    in the way that they specify the starting and ending addresses.
+
+2.  <i>Default location description</i>
+
+    This kind of location list entry provides an operation expression that
+    evaluates to the location description of an object that is valid when no
+    bounded location description entry applies.
+
+    The location list entry matches when the current program location is not
+    within the range of any bounded location description entry.
+
+3.  <i>Base address</i>
+
+    This kind of location list entry provides an address to be used as the base
+    address for beginning and ending address offsets given in certain kinds of
+    bounded location description entries. The applicable base address of a
+    bounded location description entry is the address specified by the closest
+    preceding base address entry in the same location list. If there is no
+    preceding base address entry, then the applicable base address defaults to
+    the base address of the compilation unit (see DWARF Version 5 section
+    3.1.1).
+
+    In the case of a compilation unit where all of the machine code is contained
+    in a single contiguous section, no base address entry is needed.
+
+4.  <i>End-of-list</i>
+
+    This kind of location list entry marks the end of the location list
+    expression.
+
+The address ranges defined by the bounded location description entries of a
+location list expression may overlap. When they do, they describe a situation in
+which an object exists simultaneously in more than one place.
+
+If all of the address ranges in a given location list expression do not
+collectively cover the entire range over which the object in question is
+defined, and there is no following default location description entry, it is
+assumed that the object is not available for the portion of the range that is
+not covered.
+
+The result of the evaluation of a DWARF location list expression is:
+
+- If the current program location is not specified, then it is an evaluation
+  error.
+
+  > NOTE: If the location list only has a single default entry, should that be
+  > considered a match if there is no program location? If there are non-default
+  > entries then it seems it has to be an evaluation error when there is no
+  > program location as that indicates the location depends on the program
+  > location which is not known.
+
+- If there are no matching location list entries, then the result is a location
+  description that comprises one undefined location description.
+- Otherwise, the operation expression E of each matching location list entry is
+  evaluated with the current context, except that the result kind is a location
+  description, the object is unspecified, and the initial stack is empty. The
+  location list entry result is the location description returned by the
+  evaluation of E.
+
+  The result is a location description that is comprised of the union of the
+  single location descriptions of the location description result of each
+  matching location list entry.
+
+A location list expression can only be used as the value of a debugger
+information entry attribute that is encoded using class `loclist` or
+`loclistsptr` (see [7.5.5 Classes and Forms](#classes-and-forms)). The value of
+the attribute provides an index into a separate object file section called
+`.debug_loclists` or `.debug_loclists.dwo` (for split DWARF object files) that
+contains the location list entries.
+
+A `DW_OP_call*` and `DW_OP_implicit_pointer` operation can be used to specify a
+debugger information entry attribute that has a location list expression.
+Several debugger information entry attributes allow DWARF expressions that are
+evaluated with an initial stack that includes a location description that may
+originate from the evaluation of a location list expression.
+
+<i>This location list representation, the `loclist` and `loclistsptr` class, and
+the related `DW_AT_loclists_base` attribute are new in DWARF Version 5. Together
+they eliminate most, or all of the code object relocations previously needed for
+location list expressions.</i>
+
+> NOTE: The rest of this section is the same as DWARF Version 5 section 2.6.2.
+
+## A.3 Program Scope Entries
+
+> NOTE: This section provides changes to existing debugger information entry
+> attributes. These would be incorporated into the corresponding DWARF Version 5
+> chapter 3 sections.
+
+### A.3.3 Subroutine and Entry Point Entries
+
+#### A.3.3.5 Low-Level Information
+
+1.  A `DW_TAG_subprogram`, `DW_TAG_inlined_subroutine`, or `DW_TAG_entry_point`
+    debugger information entry may have a `DW_AT_return_addr` attribute, whose
+    value is a DWARF expression E.
+
+    The result of the attribute is obtained by evaluating E with a context that
+    has a result kind of a location description, an unspecified object, the
+    compilation unit that contains E, an empty initial stack, and other context
+    elements corresponding to the source language thread of execution upon which
+    the user is focused, if any. The result of the evaluation is the location
+    description L of the place where the return address for the current call
+    frame's subprogram or entry point is stored.
+
+    The DWARF is ill-formed if L is not comprised of one memory location
+    description for one of the target architecture specific address spaces.
+
+    > NOTE: It is unclear why `DW_TAG_inlined_subroutine` has a
+    > `DW_AT_return_addr` attribute but not a `DW_AT_frame_base` or
+    > `DW_AT_static_link` attribute. Seems it would either have all of them or
+    > none. Since inlined subprograms do not have a call frame it seems they
+    > would have none of these attributes.
+
+2.  A `DW_TAG_subprogram` or `DW_TAG_entry_point` debugger information entry may
+    have a `DW_AT_frame_base` attribute, whose value is a DWARF expression E.
+
+    The result of the attribute is obtained by evaluating E with a context that
+    has a result kind of a location description, an unspecified object, the
+    compilation unit that contains E, an empty initial stack, and other context
+    elements corresponding to the source language thread of execution upon which
+    the user is focused, if any.
+
+    The DWARF is ill-formed if E contains an `DW_OP_fbreg` operation, or the
+    resulting location description L is not comprised of one single location
+    description SL.
+
+    If SL is a register location description for register R, then L is replaced
+    with the result of evaluating a `DW_OP_bregx R, 0` operation. This computes
+    the frame base memory location description in the target architecture
+    default address space.
+
+    <i>This allows the more compact `DW_OP_reg*` to be used instead of
+    `DW_OP_breg* 0`.</i>
+
+    > NOTE: This rule could be removed and require the producer to create the
+    > required location description directly using `DW_OP_call_frame_cfa` or
+    > `DW_OP_breg*`. This would also then allow a target to implement the call
+    > frames within a large register.
+
+    Otherwise, the DWARF is ill-formed if SL is not a memory location
+    description in any of the target architecture specific address spaces.
+
+    The resulting L is the <i>frame base</i> for the subprogram or entry point.
+
+    <i>Typically, E will use the `DW_OP_call_frame_cfa` operation or be a stack
+    pointer register plus or minus some offset.</i>
+
+3.  If a `DW_TAG_subprogram` or `DW_TAG_entry_point` debugger information entry
+    is lexically nested, it may have a `DW_AT_static_link` attribute, whose
+    value is a DWARF expression E.
+
+    The result of the attribute is obtained by evaluating E with a context that
+    has a result kind of a location description, an unspecified object, the
+    compilation unit that contains E, an empty initial stack, and other context
+    elements corresponding to the source language thread of execution upon which
+    the user is focused, if any. The result of the evaluation is the location
+    description L of the <i>canonical frame address</i> (see [6.4 Call Frame
+    Information](#call-frame-information)) of the relevant call frame of the
+    subprogram instance that immediately lexically encloses the current call
+    frame's subprogram or entry point.
+
+    The DWARF is ill-formed if L is is not comprised of one memory location
+    description for one of the target architecture specific address spaces.
+
+### A.3.4 Call Site Entries and Parameters
+
+#### A.3.4.2 Call Site Parameters
+
+1.  A `DW_TAG_call_site_parameter` debugger information entry may have a
+    `DW_AT_call_value` attribute, whose value is a DWARF operation expression
+    E<sub>1</sub>.
+
+    The result of the `DW_AT_call_value` attribute is obtained by evaluating
+    E<sub>1</sub> with a context that has a result kind of a value, an unspecified
+    object, the compilation unit that contains E, an empty initial stack, and other
+    context elements corresponding to the source language thread of execution upon
+    which the user is focused, if any. The resulting value V<sub>1</sub> is the
+    value of the parameter at the time of the call made by the call site.
+
+    For parameters passed by reference, where the code passes a pointer to a
+    location which contains the parameter, or for reference type parameters, the
+    `DW_TAG_call_site_parameter` debugger information entry may also have a
+    `DW_AT_call_data_location` attribute whose value is a DWARF operation expression
+    E<sub>2</sub>, and a `DW_AT_call_data_value` attribute whose value is a DWARF
+    operation expression E<sub>3</sub>.
+
+    The value of the `DW_AT_call_data_location` attribute is obtained by evaluating
+    E<sub>2</sub> with a context that has a result kind of a location description,
+    an unspecified object, the compilation unit that contains E, an empty initial
+    stack, and other context elements corresponding to the source language thread of
+    execution upon which the user is focused, if any. The resulting location
+    description L<sub>2</sub> is the location where the referenced parameter lives
+    during the call made by the call site. If E<sub>2</sub> would just be a
+    `DW_OP_push_object_address`, then the `DW_AT_call_data_location` attribute may
+    be omitted.
+
+    > NOTE: The DWARF Version 5 implies that `DW_OP_push_object_address` may be
+    > used but does not state what object must be specified in the context.
+    > Either `DW_OP_push_object_address` cannot be used, or the object to be
+    > passed in the context must be defined.
+
+    The value of the `DW_AT_call_data_value` attribute is obtained by evaluating
+    E<sub>3</sub> with a context that has a result kind of a value, an unspecified
+    object, the compilation unit that contains E, an empty initial stack, and other
+    context elements corresponding to the source language thread of execution upon
+    which the user is focused, if any. The resulting value V<sub>3</sub> is the
+    value in L<sub>2</sub> at the time of the call made by the call site.
+
+    The result of these attributes is undefined if the current call frame is not for
+    the subprogram containing the `DW_TAG_call_site_parameter` debugger information
+    entry or the current program location is not for the call site containing the
+    `DW_TAG_call_site_parameter` debugger information entry in the current call
+    frame.
+
+    <i>The consumer may have to virtually unwind to the call site (see [6.4 Call
+    Frame Information](#call-frame-information)) in order to evaluate these
+    attributes. This will ensure the source language thread of execution upon which
+    the user is focused corresponds to the call site needed to evaluate the
+    expression.</i>
+
+    If it is not possible to avoid the expressions of these attributes from
+    accessing registers or memory locations that might be clobbered by the
+    subprogram being called by the call site, then the associated attribute should
+    not be provided.
+
+    <i>The reason for the restriction is that the parameter may need to be accessed
+    during the execution of the callee. The consumer may virtually unwind from the
+    called subprogram back to the caller and then evaluate the attribute
+    expressions. The call frame information (see [6.4 Call Frame
+    Information](#call-frame-information)) will not be able to restore registers
+    that have been clobbered, and clobbered memory will no longer have the value at
+    the time of the call.</i>
+
+### A.3.5 Lexical Block Entries
+
+> NOTE: This section is the same as DWARF Version 5 section 3.5.
+
+## A.4 Data Object and Object List Entries
+
+> NOTE: This section provides changes to existing debugger information entry
+> attributes. These would be incorporated into the corresponding DWARF Version 5
+> chapter 4 sections.
+
+### A.4.1 Data Object Entries
+
+1.  Any debugging information entry describing a data object (which includes
+    variables and parameters) or common blocks may have a `DW_AT_location`
+    attribute, whose value is a DWARF expression E.
+
+    The result of the attribute is obtained by evaluating E with a context that
+    has a result kind of a location description, an unspecified object, the
+    compilation unit that contains E, an empty initial stack, and other context
+    elements corresponding to the source language thread of execution upon which
+    the user is focused, if any. The result of the evaluation is the location
+    description of the base of the data object.
+
+    See [2.5.4.2 Control Flow Operations](#control-flow-operations) for special
+    evaluation rules used by the `DW_OP_call*` operations.
+
+    > NOTE: Delete the description of how the `DW_OP_call*` operations evaluate
+    > a `DW_AT_location` attribute as that is now described in the operations.
+
+    > NOTE: See the discussion about the `DW_AT_location` attribute in the
+    > `DW_OP_call*` operation. Having each attribute only have a single purpose
+    > and single execution semantics seems desirable. It makes it easier for the
+    > consumer that no longer have to track the context. It makes it easier for
+    > the producer as it can rely on a single semantics for each attribute.
+    >
+    > For that reason, limiting the `DW_AT_location` attribute to only
+    > supporting evaluating the location description of an object, and using a
+    > different attribute and encoding class for the evaluation of DWARF
+    > expression <i>procedures</i> on the same operation expression stack seems
+    > desirable.
+
+2.  `DW_AT_const_value`
+
+    > NOTE: Could deprecate using the `DW_AT_const_value` attribute for
+    > `DW_TAG_variable` or `DW_TAG_formal_parameter` debugger information
+    > entries that have been optimized to a constant. Instead, `DW_AT_location`
+    > could be used with a DWARF expression that produces an implicit location
+    > description now that any location description can be used within a DWARF
+    > expression. This allows the `DW_OP_call*` operations to be used to push
+    > the location description of any variable regardless of how it is
+    > optimized.
+
+## A.5 Type Entries
+
+> NOTE: This section provides changes to existing debugger information entry
+> attributes. These would be incorporated into the corresponding DWARF Version 5
+> chapter 5 sections.
+
+### A.5.7 Structure, Union, Class and Interface Type Entries
+
+#### A.5.7.3 Derived or Extended Structures, Classes and Interfaces
+
+1.  For a `DW_AT_data_member_location` attribute there are two cases:
+
+    1.  If the attribute is an integer constant B, it provides the offset in
+        bytes from the beginning of the containing entity.
+
+        The result of the attribute is obtained by updating the bit offset of
+        the location description of the beginning of the containing entity by B
+        scaled by 8 (the byte size). The result is the location description of
+        the base of the member entry.
+
+        <i>If the beginning of the containing entity is not byte aligned, then
+        the beginning of the member entry has the same bit displacement within a
+        byte.</i>
+
+    2.  Otherwise, the attribute must be a DWARF expression E which is evaluated
+        with a context that has a result kind of a location description, an
+        unspecified object, the compilation unit that contains E, an initial
+        stack comprising the location description of the beginning of the
+        containing entity, and other context elements corresponding to the
+        source language thread of execution upon which the user is focused, if
+        any. The result of the evaluation is the location description of the
+        base of the member entry.
+
+    > NOTE: The beginning of the containing entity can now be any location
+    > description, including those with more than one single location
+    > description, and those with single location descriptions that are of any
+    > kind and have any bit offset.
+
+#### A.5.7.8 Member Function Entries
+
+1.  An entry for a virtual function also has a `DW_AT_vtable_elem_location`
+    attribute whose value is a DWARF expression E.
+
+    The result of the attribute is obtained by evaluating E with a context that
+    has a result kind of a location description, an unspecified object, the
+    compilation unit that contains E, an initial stack comprising the location
+    description of the object of the enclosing type, and other context elements
+    corresponding to the source language thread of execution upon which the user
+    is focused, if any. The result of the evaluation is the location description
+    of the slot for the function within the virtual function table for the
+    enclosing class.
+
+### A.5.14 Pointer to Member Type Entries
+
+1.  The `DW_TAG_ptr_to_member_type` debugging information entry has a
+    `DW_AT_use_location` attribute whose value is a DWARF expression E. It is used
+    to compute the location description of the member of the class to which the
+    pointer to member entry points.
+
+    <i>The method used to find the location description of a given member of a
+    class, structure, or union is common to any instance of that class, structure,
+    or union and to any instance of the pointer to member type. The method is thus
+    associated with the pointer to member type, rather than with each object that
+    has a pointer to member type.</i>
+
+    The `DW_AT_use_location` DWARF expression is used in conjunction with the
+    location description for a particular object of the given pointer to member type
+    and for a particular structure or class instance.
+
+    The result of the attribute is obtained by evaluating E with a context that has
+    a result kind of a location description, an unspecified object, the compilation
+    unit that contains E, an initial stack comprising two entries, and other context
+    elements corresponding to the source language thread of execution upon which the
+    user is focused, if any. The first stack entry is the value of the pointer to
+    member object itself. The second stack entry is the location description of the
+    base of the entire class, structure, or union instance containing the member
+    whose location is being calculated. The result of the evaluation is the location
+    description of the member of the class to which the pointer to member entry
+    points.
+
+### A.5.16 Dynamic Type Entries
+
+1.  The `DW_AT_data_location` attribute may be used with any type that provides one
+    or more levels of hidden indirection and/or run-time parameters in its
+    representation. Its value is a DWARF operation expression E which computes the
+    location description of the data for an object. When this attribute is omitted,
+    the location description of the data is the same as the location description of
+    the object.
+
+    The result of the attribute is obtained by evaluating E with a context that has
+    a result kind of a location description, an object that is the location
+    description of the data descriptor, the compilation unit that contains E, an
+    empty initial stack, and other context elements corresponding to the source
+    language thread of execution upon which the user is focused, if any. The result
+    of the evaluation is the location description of the base of the member entry.
+
+    <i>E will typically involve an operation expression that begins with a
+    `DW_OP_push_object_address` operation which loads the location description
+    of the object which can then serve as a descriptor in subsequent
+    calculation.</i>
+
+    > NOTE: Since `DW_AT_data_member_location`, `DW_AT_use_location`, and
+    > `DW_AT_vtable_elem_location` allow both operation expressions and location
+    > list expressions, why does `DW_AT_data_location` not allow both? In all cases
+    > they apply to data objects so less likely that optimization would cause
+    > different operation expressions for different program location ranges. But if
+    > supporting for some then should be for all.
+    >
+    > It seems odd this attribute is not the same as `DW_AT_data_member_location` in
+    > having an initial stack with the location description of the object since the
+    > expression has to need it.
+
+## A.6 Other Debugging Information
+
+> NOTE: This section provides changes to existing debugger information entry
+> attributes. These would be incorporated into the corresponding DWARF Version 5
+> chapter 6 sections.
+
+### A.6.2 Line Number Information
+
+> NOTE: This section is the same as DWARF Version 5 section 6.2.
+
+### A.6.4 Call Frame Information
+
+> NOTE: This section provides changes to DWARF Version 5 section 6.4. Register
+> unwind DWARF expressions are generalized to allow any location description,
+> including those with composite and implicit location descriptions.
+
+#### A.6.4.1 Structure of Call Frame Information
+
+The register rules are:
+
+1.  <i>undefined</i>
+
+    A register that has this rule has no recoverable value in the previous
+    frame. The previous value of this register is the undefined location
+    description (see [2.5.4.4.2 Undefined Location Description
+    Operations](#undefined-location-description-operations)).
+
+    <i>By convention, the register is not preserved by a callee.</i>
+
+2.  <i>same value</i>
+
+    This register has not been modified from the previous caller frame.
+
+    If the current frame is the top frame, then the previous value of this
+    register is the location description L that specifies one register location
+    description SL. SL specifies the register location storage that corresponds
+    to the register with a bit offset of 0 for the current thread.
+
+    If the current frame is not the top frame, then the previous value of this
+    register is the location description obtained using the call frame
+    information for the callee frame and callee program location invoked by the
+    current caller frame for the same register.
+
+    <i>By convention, the register is preserved by the callee, but the callee
+    has not modified it.</i>
+
+3.  <i>offset(N)</i>
+
+    N is a signed byte offset. The previous value of this register is saved at
+    the location description L. Where L is the location description of the
+    current CFA (see [2.5.4 DWARF Operation
+    Expressions](#dwarf-operation-expressions)) updated with the bit offset N
+    scaled by 8 (the byte size).
+
+4.  <i>val_offset(N)</i>
+
+    N is a signed byte offset. The previous value of this register is the memory
+    byte address of the location description L. Where L is the location
+    description of the current CFA (see [2.5.4 DWARF Operation
+    Expressions](#dwarf-operation-expressions)) updated with the bit offset N
+    scaled by 8 (the byte size).
+
+    The DWARF is ill-formed if the CFA location description is not a memory byte
+    address location description, or if the register size does not match the
+    size of an address in the target architecture default address space.
+
+    <i>Since the CFA location description is required to be a memory byte
+    address location description, the value of val_offset(N) will also be a
+    memory byte address location description since it is offsetting the CFA
+    location description by N bytes. Furthermore, the value of val_offset(N)
+    will be a memory byte address in the target architecture default address
+    space.</i>
+
+    > NOTE: Should DWARF allow the address size to be a different size to the
+    > size of the register? Requiring them to be the same bit size avoids any
+    > issue of conversion as the bit contents of the register is simply
+    > interpreted as a value of the address.
+    >
+    > GDB has a per register hook that allows a target specific conversion on a
+    > register by register basis. It defaults to truncation of bigger registers,
+    > and to actually reading bytes from the next register (or reads out of
+    > bounds for the last register) for smaller registers. There are no GDB
+    > tests that read a register out of bounds (except an illegal hand written
+    > assembly test).
+
+5.  <i>register(R)</i>
+
+    This register has been stored in another register numbered R.
+
+    The previous value of this register is the location description obtained
+    using the call frame information for the current frame and current program
+    location for register R.
+
+    The DWARF is ill-formed if the size of this register does not match the size
+    of register R or if there is a cyclic dependency in the call frame
+    information.
+
+    > NOTE: Should this also allow R to be larger than this register? If so is
+    > the value stored in the low order bits and it is undefined what is stored
+    > in the extra upper bits?
+
+6.  <i>expression(E)</i>
+
+    The previous value of this register is located at the location description
+    produced by evaluating the DWARF operation expression E (see [2.5.4 DWARF
+    Operation Expressions](#dwarf-operation-expressions)).
+
+    E is evaluated with the current context, except the result kind is a
+    location description, the compilation unit is unspecified, the object is
+    unspecified, and an initial stack comprising the location description of the
+    current CFA (see [2.5.4 DWARF Operation
+    Expressions](#dwarf-operation-expressions)).
+
+7.  <i>val_expression(E)</i>
+
+    The previous value of this register is the value produced by evaluating the
+    DWARF operation expression E (see [2.5.4 DWARF Operation
+    Expressions](#dwarf-operation-expressions)).
+
+    E is evaluated with the current context, except the result kind is a value,
+    the compilation unit is unspecified, the object is unspecified, and an
+    initial stack comprising the location description of the current CFA (see
+    [2.5.4 DWARF Operation Expressions](#dwarf-operation-expressions)).
+
+    The DWARF is ill-formed if the resulting value type size does not match the
+    register size.
+
+    > NOTE: This has limited usefulness as the DWARF expression E can only
+    > produce values up to the size of the generic type. This is due to not
+    > allowing any operations that specify a type in a CFI operation expression.
+    > This makes it unusable for registers that are larger than the generic
+    > type. However, <i>expression(E)</i> can be used to create an implicit
+    > location description of any size.
+
+8.  <i>architectural</i>
+
+    The rule is defined externally to this specification by the augmenter.
+
+A Common Information Entry (CIE) holds information that is shared among many
+Frame Description Entries (FDE). There is at least one CIE in every non-empty
+`.debug_frame` section. A CIE contains the following fields, in order:
+
+1.  `length` (initial length)
+
+    A constant that gives the number of bytes of the CIE structure, not
+    including the length field itself. The size of the length field plus the
+    value of length must be an integral multiple of the address size specified
+    in the `address_size` field.
+
+2.  `CIE_id` (4 or 8 bytes, see [7.4 32-Bit and 64-Bit DWARF
+    Formats](#32-bit-and-64-bit-dwarf-formats))
+
+    A constant that is used to distinguish CIEs from FDEs.
+
+    In the 32-bit DWARF format, the value of the CIE id in the CIE header is
+    0xffffffff; in the 64-bit DWARF format, the value is 0xffffffffffffffff.
+
+3.  `version` (ubyte)
+
+    A version number. This number is specific to the call frame information and
+    is independent of the DWARF version number.
+
+    The value of the CIE version number is 4.
+
+    > NOTE: Would this be increased to 5 to reflect the changes in these
+    > extensions?
+
+4.  `augmentation` (sequence of UTF-8 characters)
+
+    A null-terminated UTF-8 string that identifies the augmentation to this CIE
+    or to the FDEs that use it. If a reader encounters an augmentation string
+    that is unexpected, then only the following fields can be read:
+
+    - CIE: length, CIE_id, version, augmentation
+    - FDE: length, CIE_pointer, initial_location, address_range
+
+    If there is no augmentation, this value is a zero byte.
+
+    <i>The augmentation string allows users to indicate that there is additional
+    vendor and target architecture specific information in the CIE or FDE which
+    is needed to virtually unwind a stack frame. For example, this might be
+    information about dynamically allocated data which needs to be freed on exit
+    from the routine.</i>
+
+    <i>Because the `.debug_frame` section is useful independently of any
+    `.debug_info` section, the augmentation string always uses UTF-8
+    encoding.</i>
+
+5.  `address_size` (ubyte)
+
+    The size of a target address in this CIE and any FDEs that use it, in bytes.
+    If a compilation unit exists for this frame, its address size must match the
+    address size here.
+
+6.  `segment_selector_size` (ubyte)
+
+    The size of a segment selector in this CIE and any FDEs that use it, in
+    bytes.
+
+7.  `code_alignment_factor` (unsigned LEB128)
+
+    A constant that is factored out of all advance location instructions (see
+    [6.4.2.1 Row Creation Instructions](#row-creation-instructions)). The
+    resulting value is `(operand * code_alignment_factor)`.
+
+8.  `data_alignment_factor` (signed LEB128)
+
+    A constant that is factored out of certain offset instructions (see [6.4.2.2
+    CFA Definition Instructions](#cfa-definition-instructions) and [6.4.2.3
+    Register Rule Instructions](#register-rule-instructions)). The
+    resulting value is `(operand * data_alignment_factor)`.
+
+9.  `return_address_register` (unsigned LEB128)
+
+    An unsigned LEB128 constant that indicates which column in the rule table
+    represents the return address of the subprogram. Note that this column might
+    not correspond to an actual machine register.
+
+    The value of the return address register is used to determine the program
+    location of the caller frame. The program location of the top frame is the
+    target architecture program counter value of the current thread.
+
+10. `initial_instructions` (array of ubyte)
+
+    A sequence of rules that are interpreted to create the initial setting of
+    each column in the table.
+
+    The default rule for all columns before interpretation of the initial
+    instructions is the undefined rule. However, an ABI authoring body or a
+    compilation system authoring body may specify an alternate default value for
+    any or all columns.
+
+11. `padding` (array of ubyte)
+
+    Enough `DW_CFA_nop` instructions to make the size of this entry match the
+    length value above.
+
+An FDE contains the following fields, in order:
+
+1.  `length` (initial length)
+
+    A constant that gives the number of bytes of the header and instruction
+    stream for this subprogram, not including the length field itself. The size
+    of the length field plus the value of length must be an integral multiple of
+    the address size.
+
+2.  `CIE_pointer` (4 or 8 bytes, see [7.4 32-Bit and 64-Bit DWARF
+    Formats](#32-bit-and-64-bit-dwarf-formats))
+
+    A constant offset into the `.debug_frame` section that denotes the CIE that
+    is associated with this FDE.
+
+3.  `initial_location` (segment selector and target address)
+
+    The address of the first location associated with this table entry. If the
+    segment_selector_size field of this FDE's CIE is non-zero, the initial
+    location is preceded by a segment selector of the given length.
+
+4.  `address_range` (target address)
+
+    The number of bytes of program instructions described by this entry.
+
+5.  `instructions` (array of ubyte)
+
+    A sequence of table defining instructions that are described in [6.4.2 Call
+    Frame Instructions](#call-frame-instructions).
+
+6.  `padding` (array of ubyte)
+
+    Enough `DW_CFA_nop` instructions to make the size of this entry match the
+    length value above.
+
+#### A.6.4.2 Call Frame Instructions
+
+Some call frame instructions have operands that are encoded as DWARF operation
+expressions E (see [2.5.4 DWARF Operation
+Expressions](#dwarf-operation-expressions)). The DWARF operations that can be
+used in E have the following restrictions:
+
+- `DW_OP_addrx`, `DW_OP_call2`, `DW_OP_call4`, `DW_OP_call_ref`,
+  `DW_OP_const_type`, `DW_OP_constx`, `DW_OP_convert`, `DW_OP_deref_type`,
+  `DW_OP_fbreg`, `DW_OP_implicit_pointer`, `DW_OP_regval_type`,
+  `DW_OP_reinterpret`, and `DW_OP_xderef_type` operations are not allowed
+  because the call frame information must not depend on other debug sections.
+- `DW_OP_push_object_address` is not allowed because there is no object context
+  to provide a value to push.
+- `DW_OP_call_frame_cfa` and `DW_OP_entry_value` are not allowed because their
+  use would be circular.
+
+<i>Call frame instructions to which these restrictions apply include
+`DW_CFA_def_cfa_expression`, `DW_CFA_expression`, and
+`DW_CFA_val_expression`.</i>
+
+##### A.6.4.2.1 Row Creation Instructions
+
+> NOTE: These instructions are the same as in DWARF Version 5 section 6.4.2.1.
+
+##### A.6.4.2.2 CFA Definition Instructions
+
+1.  `DW_CFA_def_cfa`
+
+    The `DW_CFA_def_cfa` instruction takes two unsigned LEB128 operands
+    representing a register number R and a (non-factored) byte displacement B.
+    The required action is to define the current CFA rule to be the result of
+    evaluating the DWARF operation expression `DW_OP_bregx R, B` as a location
+    description.
+
+2.  `DW_CFA_def_cfa_sf`
+
+    The `DW_CFA_def_cfa_sf` instruction takes two operands: an unsigned LEB128
+    value representing a register number R and a signed LEB128 factored byte
+    displacement B. The required action is to define the current CFA rule to be
+    the result of evaluating the DWARF operation expression `DW_OP_bregx R, B *
+    data_alignment_factor` as a location description.
+
+    <i>The action is the same as `DW_CFA_def_cfa`, except that the second
+    operand is signed and factored.</i>
+
+3.  `DW_CFA_def_cfa_register`
+
+    The `DW_CFA_def_cfa_register` instruction takes a single unsigned LEB128
+    operand representing a register number R. The required action is to define
+    the current CFA rule to be the result of evaluating the DWARF operation
+    expression `DW_OP_bregx R, B` as a location description. B is the old CFA
+    byte displacement.
+
+    If the subprogram has no current CFA rule, or the rule was defined by a
+    `DW_CFA_def_cfa_expression` instruction, then the DWARF is ill-formed.
+
+4.  `DW_CFA_def_cfa_offset`
+
+    The `DW_CFA_def_cfa_offset` instruction takes a single unsigned LEB128
+    operand representing a (non-factored) byte displacement B. The required
+    action is to define the current CFA rule to be the result of evaluating the
+    DWARF operation expression `DW_OP_bregx R, B` as a location description. R
+    is the old CFA register number.
+
+    If the subprogram has no current CFA rule, or the rule was defined by a
+    `DW_CFA_def_cfa_expression` instruction, then the DWARF is ill-formed.
+
+5.  `DW_CFA_def_cfa_offset_sf`
+
+    The `DW_CFA_def_cfa_offset_sf` instruction takes a signed LEB128 operand
+    representing a factored byte displacement B. The required action is to
+    define the current CFA rule to be the result of evaluating the DWARF
+    operation expression `DW_OP_bregx R, B * data_alignment_factor` as a
+    location description. R is the old CFA register number.
+
+    If the subprogram has no current CFA rule, or the rule was defined by a
+    `DW_CFA_def_cfa_expression` instruction, then the DWARF is ill-formed.
+
+    <i>The action is the same as `DW_CFA_def_cfa_offset`, except that the
+    operand is signed and factored.</i>
+
+6.  `DW_CFA_def_cfa_expression`
+
+    The `DW_CFA_def_cfa_expression` instruction takes a single operand encoded
+    as a `DW_FORM_exprloc` value representing a DWARF operation expression E.
+    The required action is to define the current CFA rule to be the result of
+    evaluating E with the current context, except the result kind is a location
+    description, the compilation unit is unspecified, the object is unspecified,
+    and an empty initial stack.
+
+    <i>See [6.4.2 Call Frame Instructions](#call-frame-instructions) regarding
+    restrictions on the DWARF expression operations that can be used in E.</i>
+
+    The DWARF is ill-formed if the result of evaluating E is not a memory byte
+    address location description.
+
+##### A.6.4.2.3 Register Rule Instructions
+
+1.  `DW_CFA_undefined`
+
+    The `DW_CFA_undefined` instruction takes a single unsigned LEB128 operand
+    that represents a register number R. The required action is to set the rule
+    for the register specified by R to `undefined`.
+
+2.  `DW_CFA_same_value`
+
+    The `DW_CFA_same_value` instruction takes a single unsigned LEB128 operand
+    that represents a register number R. The required action is to set the rule
+    for the register specified by R to `same value`.
+
+3.  `DW_CFA_offset`
+
+    The `DW_CFA_offset` instruction takes two operands: a register number R
+    (encoded with the opcode) and an unsigned LEB128 constant representing a
+    factored displacement B. The required action is to change the rule for the
+    register specified by R to be an <i>offset(B * data_alignment_factor)</i>
+    rule.
+
+    > NOTE: Seems this should be named `DW_CFA_offset_uf` since the offset is
+    > unsigned factored.
+
+4.  `DW_CFA_offset_extended`
+
+    The `DW_CFA_offset_extended` instruction takes two unsigned LEB128 operands
+    representing a register number R and a factored displacement B. This
+    instruction is identical to `DW_CFA_offset`, except for the encoding and
+    size of the register operand.
+
+    > NOTE: Seems this should be named `DW_CFA_offset_extended_uf` since the
+    > displacement is unsigned factored.
+
+5.  `DW_CFA_offset_extended_sf`
+
+    The `DW_CFA_offset_extended_sf` instruction takes two operands: an unsigned
+    LEB128 value representing a register number R and a signed LEB128 factored
+    displacement B. This instruction is identical to `DW_CFA_offset_extended`,
+    except that B is signed.
+
+6.  `DW_CFA_val_offset`
+
+    The `DW_CFA_val_offset` instruction takes two unsigned LEB128 operands
+    representing a register number R and a factored displacement B. The required
+    action is to change the rule for the register indicated by R to be a
+    <i>val_offset(B * data_alignment_factor)</i> rule.
+
+    > NOTE: Seems this should be named `DW_CFA_val_offset_uf` since the
+    displacement is unsigned factored.
+
+7.  `DW_CFA_val_offset_sf`
+
+    The `DW_CFA_val_offset_sf` instruction takes two operands: an unsigned
+    LEB128 value representing a register number R and a signed LEB128 factored
+    displacement B. This instruction is identical to `DW_CFA_val_offset`, except
+    that B is signed.
+
+8.  `DW_CFA_register`
+
+    The `DW_CFA_register` instruction takes two unsigned LEB128 operands
+    representing register numbers R1 and R2 respectively. The required action is
+    to set the rule for the register specified by R1 to be a <i>register(R2)</i>
+    rule.
+
+9.  `DW_CFA_expression`
+
+    The `DW_CFA_expression` instruction takes two operands: an unsigned LEB128
+    value representing a register number R, and a `DW_FORM_block` value
+    representing a DWARF operation expression E. The required action is to
+    change the rule for the register specified by R to be an
+    <i>expression(E)</i> rule.
+
+    <i>That is, E computes the location description where the register value can
+    be retrieved.</i>
+
+    <i>See [6.4.2 Call Frame Instructions](#call-frame-instructions) regarding
+    restrictions on the DWARF expression operations that can be used in E.</i>
+
+10. `DW_CFA_val_expression`
+
+    The `DW_CFA_val_expression` instruction takes two operands: an unsigned
+    LEB128 value representing a register number R, and a `DW_FORM_block` value
+    representing a DWARF operation expression E. The required action is to
+    change the rule for the register specified by R to be a
+    <i>val_expression(E)</i> rule.
+
+    <i>That is, E computes the value of register R.</i>
+
+    <i>See [6.4.2 Call Frame Instructions](#call-frame-instructions) regarding
+    restrictions on the DWARF expression operations that can be used in E.</i>
+
+    If the result of evaluating E is not a value with a base type size that
+    matches the register size, then the DWARF is ill-formed.
+
+11. `DW_CFA_restore`
+
+    The `DW_CFA_restore` instruction takes a single operand (encoded with the
+    opcode) that represents a register number R. The required action is to
+    change the rule for the register specified by R to the rule assigned it by
+    the `initial_instructions` in the CIE.
+
+12. `DW_CFA_restore_extended`
+
+    The `DW_CFA_restore_extended` instruction takes a single unsigned LEB128
+    operand that represents a register number R. This instruction is identical
+    to `DW_CFA_restore`, except for the encoding and size of the register
+    operand.
+
+##### A.6.4.2.4 Row State Instructions
+
+> NOTE: These instructions are the same as in DWARF Version 5 section 6.4.2.4.
+
+##### A.6.4.2.5 Padding Instruction
+
+> NOTE: These instructions are the same as in DWARF Version 5 section 6.4.2.5.
+
+#### A.6.4.3 Call Frame Instruction Usage
+
+> NOTE: The same as in DWARF Version 5 section 6.4.3.
+
+#### A.6.4.4 Call Frame Calling Address
+
+> NOTE: The same as in DWARF Version 5 section 6.4.4.
+
+## A.7 Data Representation
+
+> NOTE: This section provides changes to existing debugger information entry
+> attributes. These would be incorporated into the corresponding DWARF Version 5
+> chapter 7 sections.
+
+### A.7.4 32-Bit and 64-Bit DWARF Formats
+
+> NOTE: This augments DWARF Version 5 section 7.4 list item 3's table.
+
+    Form                     Role
+    ------------------------ --------------------------------------
+    DW_OP_implicit_pointer   offset in `.debug_info`
+
+### A.7.5 Format of Debugging Information
+
+#### A.7.5.5 Classes and Forms
+
+> NOTE: The same as in DWARF Version 5 section 7.5.5.
+
+### A.7.7 DWARF Expressions
+
+> NOTE: Rename DWARF Version 5 section 7.7 to reflect the unification of
+> location descriptions into DWARF expressions.
+
+#### A.7.7.1 Operation Expressions
+
+> NOTE: Rename DWARF Version 5 section 7.7.1 and delete section 7.7.2 to reflect
+> the unification of location descriptions into DWARF expressions.
+
+#### A.7.7.3 Location List Expressions
+
+> NOTE: Rename DWARF Version 5 section 7.7.3 to reflect that location lists are
+> a kind of DWARF expression.
+
+# B. Further Information
+
+The following references provide additional information on the extension.
+
+A reference to the DWARF standard is provided.
+
+A formatted version of this extension is available on the LLVM site. It includes
+many figures that help illustrate the textual description, especially of the
+example DWARF expression evaluations.
+
+Slides and a video of a presentation at the Linux Plumbers Conference 2021
+related to this extension are available.
+
+The LLVM compiler extension includes the operations mentioned in the motivating
+examples. It also covers other extensions needed for heterogeneous devices.
+
+- [DWARF Debugging Information Format](https://dwarfstd.org/)
+  - [DWARF Debugging Information Format Version 5](https://dwarfstd.org/Dwarf5Std.php)
+- [Allow Location Descriptions on the DWARF Expression Stack](https://llvm.org/docs/AMDGPUDwarfExtensionAllowLocationDescriptionOnTheDwarfExpressionStack/AMDGPUDwarfExtensionAllowLocationDescriptionOnTheDwarfExpressionStack.html)
+- DWARF extensions for optimized SIMT/SIMD (GPU) debugging - Linux Plumbers Conference 2021
+  - [Video](https://www.youtube.com/watch?v=QiR0ra0ymEY&t=10015s)
+  - [Slides](https://linuxplumbersconf.org/event/11/contributions/1012/attachments/798/1505/DWARF_Extensions_for_Optimized_SIMT-SIMD_GPU_Debugging-LPC2021.pdf)
+- [DWARF Extensions For Heterogeneous Debugging](https://llvm.org/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.html)