Lines Matching full:the

1 # Allow Location Descriptions on the DWARF Expression Stack <!-- omit in toc -->
14 that allows both typed values and location descriptions to be manipulated on the
16 on the stack. In addition, the call frame information (CFI) is extended to
17 support the full generality of location descriptions. This is done in a manner
18 that is backwards compatible with DWARF 5. The extension involves changes to the
21 The extension permits operations to act on location descriptions in an
23 operations to be defined to address the requirements of heterogeneous devices as
29 rules. However, these resulted in the need for more operations that did not
31 corner cases that had to be defined. The observation was that numerous
37 describes heterogeneous devices and the features they have that are not addressed by DWARF 5.
38 Then section [3. DWARF5](#dwarf-5) presents a brief simplified overview of the DWARF 5 expression
39 evaluation model that highlights the difficulties for supporting the
41 Solution](#extension-solution) provides an overview of the proposal, using
42 simplified examples to illustrate how it can address the issues of heterogeneous
46 relative to the DWARF Version 5 standard. Finally, appendix
55 memory accesses which tend to be more expensive than on a CPU due to the much
61 They may support masked vector instructions that are used by the compiler to map
62 high level language threads onto the lanes of the vector registers. As a
63 consequence, multiple language threads execute in lockstep as the vector
69 GPUs can have multiple memory address spaces in addition to the single global
82 Through optimization, the source variables may be located across these different
84 of runtime defined pieces of vector registers. With the more complex locations,
90 Before presenting the proposed solution to supporting heterogeneous devices, a
91 brief overview of the DWARF 5 expression evaluation model will be given to
92 highlight the aspects being addressed by the extension.
98 It is either embedded directly in sections of the code object executables, or
106 - It maps a source language function to the hardware instruction program counter
112 - In addition, it provides numerous other information about the source language
115 In particular, there is great diversity in the way a source language entity
116 could be mapped to a hardware location. The location may involve runtime values.
121 - At an offset from the current stack pointer.
125 - Spread across combination of the above kinds of locations.
129 expressions and operation expressions. Loclist expressions allow the result to
130 vary depending on the PC. Operation expressions are made up of a list of
133 A DWARF expression can be used as the value of different attributes of different
136 expression is evaluated in a context dictated by where it is used. The context
139 - Whether the expression needs to produce a value or the location of an entity.
140 - The current execution point including process, thread, PC, and stack frame.
141 - Some expressions are evaluated with the stack initialized with a specific
142   value or with the location of a base object that is available using the
147 The following examples illustrate how DWARF expressions involving operations are
153 The first example is for an operation expression associated with a DIE attribute
154 that provides the number of elements in a dynamic array type. Such an attribute
155 dictates that the expression must be evaluated in the context of providing a
160 In this hypothetical example, the compiler has allocated an array descriptor in
161 memory and placed the descriptor's address in architecture register SGPR0. The
162 first location of the array descriptor is the runtime size of the array.
164 A possible expression to retrieve the dynamic size of the array is:
169 The expression is evaluated one operation at a time. Operations have operands
174 The expression evaluation starts with the first DW_OP_regval_type operation.
175 This operation reads the current value of an architecture register specified by
176 its first operand: SGPR0. The second operand specifies the size of the data to
177 read. The read value is pushed on the stack. Each stack element is a value and
182 The type must be a DWARF base type. It specifies the encoding, byte ordering,
183 and size of values of the type. DWARF defines that each architecture has a
185 ordering, that is the size of the architecture's global memory address.
187 The DW_OP_deref operation pops a value off the stack, treats it as a global
188 memory address, and reads the contents of that location using the generic type.
189 It pushes the read value on the stack as the value and its associated generic
194 The evaluation stops when it reaches the end of the expression. The result of an
195 expression that is evaluated with a value result kind context is the top element
196 of the stack, which provides the value and its type.
201 provides the location of a source language variable. Such an attribute dictates
202 that the expression must be evaluated in the context of providing a location
205 DWARF defines the locations of objects in terms of location descriptions.
207 In this example, the compiler has allocated a source language variable in
212 A possible expression to specify the location of the variable is:
218 The DW_OP_regx operation creates a location description that specifies the
219 location of the architecture register specified by the operand: SGPR0. Unlike
220 values, location descriptions are not pushed on the stack. Instead they are
222 not have an associated type, they only denote the location of the base of the
227 Again, evaluation stops when it reaches the end of the expression. The result of
228 an expression that is evaluated with a location result kind context is the
229 location description in the location area.
233 The next example is for an operation expression associated with a DIE attribute
234 that provides the location of a source language variable that is allocated in a
235 stack frame. The compiler has placed the stack frame pointer in architecture
236 register SGPR0, and allocated the variable at offset 0x10 from the stack frame
237 base. The stack frames are allocated in global memory, so SGPR0 contains a
242 A possible expression to specify the location of the variable is:
249 As in the previous example, the DW_OP_regval_type operation pushes the stack
250 frame pointer global memory address onto the stack. The generic type is the size
255 The DW_OP_plus_uconst operation pops a value from the stack, which must have a
256 type with an integral encoding, adds the value of its operand, and pushes the
257 result back on the stack with the same associated type. In this example, that
258 computes the global memory address of the source language variable.
262 Evaluation stops when it reaches the end of the expression. If the expression
263 that is evaluated has a location result kind context, and the location area is
264 empty, then the top stack element must be a value with the generic type. The
265 value is implicitly popped from the stack, and treated as a global memory
266 address to create a global memory location description, which is placed in the
267 location area. The result of the expression is the location description in the
279 Each part specifies a location description and the number of bytes used from it.
280 The following operation expression creates a composite location description.
290 The DW_OP_regx operation creates a register location description in the location
295 The first DW_OP_piece operation creates an incomplete composite location
296 description in the location area with a single part. The location description in
297 the location area is used to define the beginning of the part for the size
298 specified by the operand, namely 4 bytes.
303 description already in the location area. The parts form a contiguous set of
304 bytes. If there are no other location descriptions in the location area, and no
305 value on the stack, then the part implicitly uses the undefined location
306 description. Again, the operand specifies the size of the part in bytes. The
312 The DW_OP_bregx operation reads the architecture register specified by the first
313 operand (SGPR0) as the generic type, adds the value of the second operand
314 (0x10), and pushes the value on the stack.
318 The next DW_OP_piece operation adds another part to the already created
321 If there is no other location in the location area, but there is a value on
322 stack, the new part is a memory location description. The memory address used is
323 popped from the stack. In this case, the operand of 2 indicates there are 2
328 Evaluation stops when it reaches the end of the expression. If the expression
329 that is evaluated has a location result kind context, and the location area has
330 an incomplete composite location description, the incomplete composite location
331 is implicitly converted to a complete composite location description. The result
332 of the expression is the location description in the location area.
338 This example attempts to extend the previous example to offset the composite
339 location description it created. The [3.2.3 Variable Location in
340 Memory](#variable-location-in-memory) example conveniently used the DW_OP_plus
353 operates on the stack.
357 To offset a composite location description, the compiler would need to make a
358 different composite location description, starting at the part corresponding to
359 the offset. For example:
371 > support for DWARF 5 is not present in the versions of the tools used. No
374 This example highlights the inability of DWARF 5 to describe C++
377 The mechanism DWARF 5 provides for describing pointer-to-member use is
379 computes the address of the member pointed to by a pointer-to-member, given the
380 pointer-to-member object and the address of the containing object.
383 operation, it first pushes two values onto the DWARF expression stack:
385 * The pointer-to-member object
386 * The address of the containing object
388 It then evaluates the location description associated with the
389 `DW_AT_use_location` of the pointer-to-member type, and interprets the result
390 as the address of the member pointed to by the pointer-to-member.
392 Consider the following C++ source file `s.cc`:
434 Note the location description for `DW_AT_use_location` is `DW_OP_plus`, which
435 reflects the GCC implementation of the pointer-to-member as an integral byte
436 offset within the containing object. For example, the value of `&s::m` in this
437 implementation is `offsetof(s, m)` and the value of `&s::n` is `offsetof(s, n)`:
453 The expression `DW_OP_plus` accurately describes this implementation so long as
454 the entire containing object resides in memory in the default address space.
456 However, what if the containing object or the member pointed to are not at any
459 The compiler may store the containing object in memory in any address space,
463 The richness of the existing DWARF 5 expression language is a reflection of the
465 affecting the location of an object in a program, and (modulo address spaces)
466 it can describe all of these locations for variables. However, the moment we
468 contiguous piece of memory in the default address space.
470 To demonstrate the problem, consider a program which GCC chooses to optimize in
471 such a way that the containing object is not in memory at all:
522 Note that the compiler has promoted the entire object `x` into register `rdi`
523 for the body of the loop:
546 With location descriptions on the stack, the definition of `DW_OP_use_location`
550 To implement the fully generalized version of this attribute, GCC would only
551 need to change the expression from `DW_OP_plus` to `DW_OP_swap,
557 > support for DWARF 5 is not present in the versions of the tools used. No
560 This example highlights the inability of DWARF 5 to describe C++
563 The mechanism DWARF 5 provides for describing the location of an inherited
568 * If an integral constant form, it encodes the byte offset from the derived
569   object to the data member or subobject.
570 * Otherwise, it encodes a location description to compute the address of the
571   data member or subobject given the address of the derived object.
573 Only the attribute describing a subobject, and only the location description
576 In this case, when a debug agent wishes to locate the subobject, it first
577 pushes the address of the derived object onto the DWARF expression stack. It
578 then evaluates the location description associated with the
579 `DW_AT_data_member_location` of the `DW_TAG_inheritence` DIE corresponding to
580 the inherited subobject.
582 Consider the following C++ source file `ab.cc`:
615 This `DW_AT_data_member_location` expression describes the dynamic process of
616 locating the `A`-in-`B` subobject according to the [Itanium
618 of the logical layout of class `B` is:
627 That is, the address of an object of class `B` is equivalent to the address for
628 the `vtable` pointer for `B`. As there are no other direct data members of `B`
629 the primary base class subobject of class `A` comes next, and there is no
630 intervening padding as the subobject alignment requirements are already
633 The `vtable` pointer for `B` contains an entry `vbase_offset` for each virtual
643 That is, to find the `vbase_offset` for the `A`-in-`B` subobject the address
644 `vptr B` is offset by the statically determined value `-24`.
646 Thus, in order to implement `DW_AT_data_member_location` for `A`-in-`B`, the
648 `vptr B` to lookup `vbase_offset` for `A`-in-`B`. It must then offset the
649 location of `B` by the dynamic value of `vbase_offset` (in this case `8`) to
650 arrive at the location of the inherited subobject.
652 This definition shares the same problem as example [3.2.6](#pointer-to-member)
653 in that it relies on the address of the derived object and inherited subobject,
656 To demonstrate the problem, consider a program which GCC chooses to optimize in
657 such a way that the derived object is not in memory at all:
702 Note that the compiler has elided storage for the entire object `x` in the
727 > NOTE: The `vptr B` which should occupy the first 8 bytes of the object `b`
728 > are undefined in the DWARF, but could be described as an implicit value by
729 > the compiler. This change would be trivial and would directly expose the
732 With location descriptions on the stack, the definition of
736 To implement the fully generalized version of this attribute, GCC would only
737 need to change the last operation in the expression from `DW_OP_plus` to
746 Some features only work when located in global memory. The type attribute
750 the ability to factorize the creation of locations that involve other location
756 Only the dereference operation supports providing an address space.
768 This section outlines the extension to generalize the DWARF expression evaluation
769 model to allow location descriptions to be manipulated on the stack. It presents
770 a number of simplified examples to demonstrate the benefits and how the extension
771 solves the issues of heterogeneous devices. It presents how this is done in
777 descriptions, the extension defines a uniform way to handle all location kinds.
782 piece of storage. The storage is a contiguous linear organization of a certain
786 - For global memory, the storage is the linear stream of bytes of the
788 - For each separate architecture register, it is the linear stream of bytes of
789   the size of that specific register.
790 - For an implicit, it is the linear stream of bytes of the value when
791   represented using the value's base type which specifies the encoding, size,
795 - For composite, it is a linear stream of bytes defined by the composite's parts.
799 The DWARF expression stack is extended to allow each stack entry to either be a
804 continue to have the same semantics. This reflects that a memory address is
808 the expression is to be evaluated as a value or a location description.
811 are generalized to act on any location description kind. For example, the
813 value from the stack and reads the storage associated with the location kind
814 starting at the location description's offset.
817 changed to pop and push location descriptions on the stack. For example, the
822 DW_OP_offset operation that modifies the offset of the location description on
823 top of the stack. Unlike the DW_OP_plus operation that only works with memory
827 DW_OP_piece_end can be defined to explicitly indicate the last part of a
828 composite. Currently, creating a composite must always be the last operation of
831 A DW_OP_undefined operation can be defined that explicitly creates the undefined
833 when the stack is empty.
837 This section provides some motivating examples to illustrate the benefits that
838 result from allowing location descriptions on the stack.
843 that it proves has the same value for every lane of a SIMT thread in a scalar
844 register. It may then need to spill that scalar register. To avoid the high cost
845 of spilling to memory, it may spill to a fixed lane of one of the numerous
850 The following expression defines the location of a source language variable that
851 the compiler allocated in a scalar register, but had to spill to lane 5 of a
852 vector register at this point of the code.
859 The DW_OP_regx pushes a register location description on the stack. The storage
860 for the register is the size of the vector register. The register location
862 The architecture defines the byte ordering of the register.
866 The DW_OP_offset_uconst pops a location description off the stack, adds its
867 operand value to the offset, and pushes the updated location description back on
868 the stack. In this case the source language variable is being spilled to lane 5
869 and each lane's component which is 32-bits (4 bytes), so the offset is 5*4=20.
873 The result of the expression evaluation is the location description on the top
874 of the stack.
876 An alternative approach could be for the target to define distinct register
878 GPUs due to the sheer number of registers that would have to be defined. It
879 would also not permit a runtime index into part of the whole register to be used
880 as shown in the next example.
885 execution is mapped to a single lane of the GPU thread. Source language
886 variables that are mapped to a register, are mapped to the lane component of the
887 vector registers corresponding to the source language's thread of execution.
889 The location expression for such variables must therefore be executed in the
890 context of the focused source language thread of execution. A DW_OP_push_lane
891 operation can be defined to push the value of the lane for the currently focused
892 source language thread of execution. The value to use would be provided by the
893 consumer of DWARF when it evaluates the location expression.
895 If the source language variable is larger than the size of the vector register
897 thread of execution will only use the vector register components for its
902 The following expression defines the location of a source language variable that
904 that combines the two parts. It will give the correct result regardless of which
905 lane corresponds to the source language thread of execution that the user is
923 The DW_OP_regx VGPR0 pushes a location description for the first register.
927 The DW_OP_push_lane; DW_OP_uconst 4; DW_OP_mul calculates the offset for the
928 focused lanes vector register component as 4 times the lane number.
936 The DW_OP_offset adjusts the register location description's offset to the
941 The DW_OP_piece either creates a new composite location description, or adds a
942 new part to an existing incomplete one. It pops the location description to use
943 for the new part. It then pops the next stack element if it is an incomplete
945 location description with no parts. Finally it pushes the incomplete composite
946 after adding the new part.
949 composite location description. The 4 of the DW_OP_piece specifies the size of
950 the register storage that comprises the part. Note that the 4 bytes start at the
953 For backwards compatibility, if the stack is empty or the top stack element is
954 an incomplete composite, an undefined location description is used for the part.
955 If the top stack element is a generic base type value, then it is implicitly
956 converted to a global memory location description with an offset equal to the
961 The rest of the expression does the same for VGPR1. However, when the
962 DW_OP_piece is evaluated there is an incomplete composite on the stack. So the
977 At the end of the expression, if the top stack element is an incomplete
979 description and returned as the result.
985 This example is the same as the previous one, except the first 2 bytes of the
986 second vector register have been spilled to memory, and the last 2 bytes have
1004 The first 6 operations are the same.
1008 The DW_OP_addr operation pushes a global memory location description on the
1009 stack with an offset equal to the address.
1013 The next DW_OP_piece adds the global memory location description as the next 2
1014 byte part of the composite.
1018 The DW_OP_uconst 0xf00d; DW_OP_stack_value pushes an implicit location
1019 description on the stack. The storage of the implicit location description is
1020 the representation of the value 0xf00d using the generic base type's encoding,
1027 The final DW_OP_piece adds 2 bytes of the implicit location description as the
1028 third part of the composite location description.
1032 The DW_OP_piece_end operation explicitly makes the incomplete composite location
1034 composite location description to be created on the stack that can be used as
1035 the location description of another following operation. For example, the
1037 multiple composite location descriptions on the stack which can be used to pass
1039 beneficial to factor the incrementally creation of location descriptions.
1049 memory such that each lane can see a linear memory view, while the backing
1050 memory is actually being accessed in an interleaved manner so that the locations
1051 for each lanes Nth dword are contiguous. This minimizes cache lines read by the
1056 The following expression defines the location of a source language variable that
1057 is allocated at offset 0x10 in the current subprograms stack frame. The
1067 The DW_OP_regval_type operation pushes the contents of SGPR0 as a generic value.
1068 This is the register that holds the address of the current stack frame.
1072 The DW_OP_uconst operation pushes the address space number. Each architecture
1073 defines the numbers it uses in DWARF. In this case, address space 1 is being
1074 used as the per lane memory.
1078 The DW_OP_form_aspace_address operation pops a value and an address space
1080 location description is pushed which refers to the address space's storage, with
1081 an offset of the popped value.
1088 Every architecture defines address space 0 as the default global memory address
1094 The source variable is at offset 0x10 in the stack frame. The DW_OP_offset
1100 The only operations in DWARF 5 that take an address space are DW_OP_xderef*.
1101 They treat a value as the address in a specified address space, and read its
1109 allocated in a register are spilled to a stack frame that resides in the
1114 With the generalization of location descriptions on the stack, it is possible to
1115 define a DW_OP_bit_offset operation that adjusts the offset of any kind of
1116 location in terms of bits rather than bytes. The offset can be a runtime
1122 arrays. It is also not generally composable as it must be the last part of an
1125 The following example defines a location description for a source variable that
1127 used if the source variable was at a bit offset within memory or a particular
1128 address space, or if the offset is a runtime value.
1142 The DW_OP_bit_offset operation pops a value and location description from the
1143 stack. It pushes the location description after updating its offset using the
1148 The ordering of bits within a byte, like byte ordering, is defined by the target
1155 the subprogram call stack. This involves determining the location where register
1157 or global memory. As shown in the earlier examples, heterogeneous devices may
1161 Therefore, the extension extends the CFI rules to support any kind of location
1166 DWARF 5 only effectively supports byte aligned memory locations on the stack by
1168 is a problem for attributes that define DWARF expressions that require the
1172 For example, the DWARF expression of the DW_AT_data_member_location attribute is
1173 evaluated with an initial stack containing the location of a type instance
1178 A similar problem exists for DWARF expressions that use the
1179 DW_OP_push_object_address operation. This operation pushes the location of a
1180 program object associated with the attribute that defines the expression.
1182 Allowing any kind of location description on the stack permits the DW_OP_call*
1183 operations to be used to factor the creation of location descriptions. The
1184 inputs and outputs of the call are passed on the stack. For example, on GPUs an
1185 expression can be defined to describe the effective PC of inactive lanes of SIMT
1186 execution. This is naturally done by composing the result of expressions for
1188 region have its own DWARF procedure, and then calling it from the expressions of
1189 the nested control flow regions. The alternative is to make each control flow
1190 region have the complete expression which results in much larger DWARF and is
1193 GPU compilers work hard to allocate objects in the larger number of registers to
1204 The generalization allows an elegant way to add higher order operations that
1210 count. The resulting composite would effectively be a vector of element count
1211 elements with each element being the same location description of the specified
1215 out of two location descriptions, a bit mask value, and an element size. The
1217 one of the two input locations according to the bit mask.
1219 These could be used in the expression of an attribute that computes the
1220 effective PC of lanes of SIMT execution. The vector result efficiently computes
1221 the PC for each SIMT lane at once. The mask could be the hardware execution mask
1223 lanes the vector element would be the current PC, and for inactive divergent
1224 lanes the PC would correspond to the source language line at which the lane is
1229 value, and a size. The resulting composite would consist of parts that are
1230 equivalent to one of the location descriptions, but with the other location
1231 description replacing a slice defined by the offset and size. This could be used
1239 range of code may promote it to a register. If the generated code does not
1240 change the register value, then there is no need to save it back to memory.
1241 Effectively, during that range, the source variable is in both memory and a
1242 register. If a consumer, such as a debugger, allows the user to change the value
1243 of the source variable in that PC range, then it would need to change both
1246 DWARF 5 supports loclists which are able to specify the location of a source
1248 express that a source language entity is in multiple places at the same time.
1251 is adequate as non-memory location descriptions can only be computed as the last
1254 However, allowing location descriptions on the stack permits non-memory location
1255 descriptions to be used in the middle of expression evaluation. For example, the
1256 DW_OP_call* and DW_OP_implicit_pointer operations can result in evaluating the
1257 expression of a DW_AT_location attribute of a DIE. The DW_AT_location attribute
1258 allows the loclist form. So the result could include multiple location
1261 Similarly, the DWARF expression associated with attributes such as
1263 location description, or a DWARF operation expression that uses the
1264 DW_OP_push_object_address operation, may want to act on the result of another
1267 Therefore, the extension needs to define how expression operations that use those
1268 results will behave. The extension does this by generalizing the expression stack
1270 it unifies the definitions of DWARF operation expressions and loclist
1274 single location descriptions. For example, the DW_OP_offset operation adds the
1275 offset to each single location description. The DW_OP_deref* operations simply
1276 read the storage of one of the single location descriptions, since multiple
1277 single location descriptions must all hold the same value. Similarly, if the
1279 descriptions, the consumer can ensure any updates are done to all of them, and
1288 significant family of issues. It addresses the specific issues present for
1296 > Non-normative text is shown in <i>italics</i>. The section numbers generally
1297 > correspond to those in the DWARF Version 5 standard unless specified
1302 > > NOTE: Notes are included to describe how the changes are to be applied to
1303 > > the DWARF Version 5 standard. They also describe rational and issues that
1311 > 2.5 and section 2.6. It is based on the text of the existing DWARF Version 5
1316 <i>The evaluation of a DWARF expression can provide the location of an object,
1317 the value of an array bound, the length of a dynamic string, the desired value
1320 If the evaluation of a DWARF expression does not encounter an error, then it can
1325 required as the result kind.
1327 If a result kind is specified, and the result of the evaluation does not match
1328 the specified result kind, then the implicit conversions described in
1330 are performed if valid. Otherwise, the DWARF expression is ill-formed.
1332 If the evaluation of a DWARF expression encounters an evaluation error, then the
1335 > NOTE: Decided to define the concept of an evaluation error. An alternative is
1338 > encounter an evaluation error can return the undefined location description or
1342 > undefined value. The expression would then always evaluate to completion, and
1348 If a DWARF expression is ill-formed, then the result is undefined.
1350 The following sections detail the rules for when a DWARF expression is
1362 self consistent or the result of the evaluation is undefined. The context
1367     The kind of result required by the DWARF expression evaluation. If specified
1372     The target architecture thread identifier of the source program thread of
1379     <i>For example, the `DW_OP_regval_type` operation.</i>
1383     The target architecture call frame identifier. It identifies a call frame
1384     that corresponds to an active invocation of a subprogram in the current
1385     thread. It is identified by its address on the call stack. The address is
1386     referred to as the Canonical Frame Address (CFA). The call frame information
1387     is used to determine the CFA for the call frames of the current thread's
1391     support virtual unwinding of the call stack.
1393     <i>For example, the `DW_OP_*reg*` operations.</i>
1395     If specified, it must be an active call frame in the current thread.
1396     Otherwise the result is undefined.
1398     If it is the currently executing call frame, then it is termed the top call
1403     The target architecture program location corresponding to the current call
1404     frame of the current thread.
1406     The program location of the top call frame is the target architecture
1407     program counter for the current thread. The call frame information is used
1408     to obtain the value of the return address register to determine the program
1409     location of the other call frames (see [6.4 Call Frame
1412     It is required for the evaluation of location list expressions to select
1414     specify target architecture registers to support virtual unwinding of the
1419     - If the current call frame is the top call frame, it must be the current
1421     - If the current call frame F is not the top call frame, it must be the
1422       program location associated with the call site in the current caller frame
1423       F that invoked the callee frame.
1424     - Otherwise the result is undefined.
1428     The compilation unit debug information entry that contains the DWARF
1432     with the same compilation unit, including indicating if such references use
1433     the 32-bit or 64-bit DWARF format. It can also provide the default address
1436     <i>For example, the `DW_OP_constx` and `DW_OP_addrx` operations.</i>
1438     <i>Note that this compilation unit may not be the same as the compilation
1439     unit determined from the loaded code object corresponding to the current
1440     program location. For example, the evaluation of the expression E associated
1441     with a `DW_AT_location` attribute of the debug information entry operand of
1442     the `DW_OP_call*` operations is evaluated with the compilation unit that
1443     contains E and not the one that contains the `DW_OP_call*` operation
1448     The target architecture.
1454     identifiers, DWARF address space identifiers, the default address space, and
1455     the address space address sizes.</i>
1459     - If the current frame is specified, then the current target architecture
1460       must be the same as the target architecture of the current frame.
1462     - If the current frame is specified and is the top frame, and if the current
1463       thread is specified, then the current target architecture must be the same
1464       as the target architecture of the current thread.
1466     - If the current compilation unit is specified, then the current target
1467       architecture default address space address size must be the same as the
1468       `address_size` field in the header of the current compilation unit and any
1469       associated entry in the `.debug_aranges` section.
1470     - If the current program location is specified, then the current target
1471       architecture must be the same as the target architecture of any line
1473       Information](#line-number-information)) corresponding to the current
1475     - If the current program location is specified, then the current target
1476       architecture default address space address size must be the same as the
1477       `address_size` field in the header of any entry corresponding to the
1478       current program location in the `.debug_addr`, `.debug_line`,
1481     - Otherwise the result is undefined.
1485     The location description of a program object.
1487     It is required for the `DW_OP_push_object_address` operation.
1489     <i>For example, the `DW_AT_data_location` attribute on type debug
1490     information entries specifies the program object corresponding to a runtime
1491     descriptor as the current object when it evaluates its associated
1494     The result is undefined if the location description is invalid (see [2.5.3
1499     This is a list of values or location descriptions that will be pushed on the
1500     operation expression evaluation stack in the order provided before
1504     expression value with initial stack entries. In all other cases the initial
1507     The result is undefined if any location descriptions are invalid (see [2.5.3
1510 If the evaluation requires a context element that is not specified, then the
1511 result of the evaluation is an error.
1515 example, the location of a global variable may be able to be evaluated without
1516 such context. If the expression evaluates with an error then it may indicate the
1519 <i>The DWARF expression for call frame information (see [6.4 Call Frame
1521 that do not require the compilation unit context to be specified.</i>
1523 The DWARF is ill-formed if all the `address_size` fields in the headers of all
1524 the entries in the `.debug_info`, `.debug_addr`, `.debug_line`,
1532 supported base type of the target architecture. The base type specifies the
1533 size, encoding, and endianity of the literal value.
1536 > would be used for the type of the value that is produced when the
1537 > `DW_OP_deref*` operation retrieves the full contents of an implicit pointer
1538 > location storage created by the `DW_OP_implicit_pointer` operation. The
1539 > literal value would record the debugging information entry and byte
1540 > displacement specified by the associated `DW_OP_implicit_pointer` operation.
1542 There is a distinguished base type termed the generic type, which is an integral
1543 type that has the size of an address in the target architecture default address
1546 <i>The generic type is the same as the unspecified type used for stack
1551 `DW_ATE_boolean`, or any target architecture defined integral encoding in the
1559 <i>Debugging information must provide consumers a way to find the location of
1560 program variables, determine the bounds of dynamic arrays and strings, and
1561 possibly to find the base address of a subprogram's call frame or the return
1562 address of a subprogram. Furthermore, to meet the needs of recent computer
1564 describe the location of an object whose location changes over the object's
1568 Information about the location of program objects is provided by location
1573 A single location description specifies the location storage that holds a
1574 program object and a position within the location storage where the program
1575 object starts. The position within the location storage is expressed as a bit
1576 offset relative to the start of the location storage.
1580 offset. The ordering of bits within a location storage uses the bit numbering
1581 and direction conventions that are appropriate to the current language on the
1588     Corresponds to the target architecture memory address spaces.
1592     Corresponds to the target architecture registers.
1605     some from another location storage, or from disjoint parts of the same
1609 > by the `DW_OP_implicit_pointer` operation. It would specify the debugger
1610 > information entry and byte offset provided by the operations.
1615 - <i>They can be the result of evaluating a debugger information entry attribute
1617   they can describe the location of an object as long as its lifetime is either
1618   static or the same as the lexical block (see [3.5 Lexical Block
1622 - <i>They can be the result of evaluating a debugger information entry attribute
1623   that specifies a location list expression. In this usage they can describe the
1627 If a location description has more than one single location description, the
1628 DWARF expression is ill-formed if the object value held in each single location
1629 description's position within the associated location storage is not the same
1630 value, except for the parts of the value that are uninitialized.
1640 used to describe objects that reside in more than one piece of storage at the
1643 to a register for some region of code, but later code may revert to reading the
1644 value from memory as the register may be used for other purposes. For the code
1645 region where the value is in a register, any change to the object value must be
1646 made in both the register and the memory so both regions of code will read the
1650 description can read the object's value from any of the single location
1651 descriptions (since they all refer to location storage that has the same value),
1652 but must write any changed value to all the single location descriptions.</i>
1654 Updating a location description L by a bit offset B is defined as adding the
1655 value of B to the bit offset of each single location description SL of L. It is
1656 an evaluation error if the updated bit offset of any SL is less than 0 or
1657 greater than or equal to the size of the location storage specified by SL.
1659 The evaluation of an expression may require context elements to create a
1660 location description. If such a location description is accessed, the storage it
1661 denotes is that associated with the context element values specified when the
1662 location description was created, which may differ from the context at the time
1665 <i>For example, creating a register location description requires the thread
1666 context: the location storage is for the specified register of that thread.
1668 thread context: the location storage is the memory associated with that
1671 If any of the context elements required to create a location description change,
1672 the location description becomes invalid and accessing it is undefined.
1676 - <i>The thread context is required and execution causes the thread to
1678 - <i>The call frame context is required and further execution causes the call
1679   frame to return to the calling frame.</i>
1680 - <i>The program location is required and further execution of the thread
1681   occurs. That could change the location list entry or call frame information
1684   - <i>Any of the frames used in the virtual call frame unwinding return.</i>
1685   - <i>The top call frame is used, the program location is used to select the
1686     call frame information entry, and further execution of the thread
1690 object. A subsequent DWARF expression evaluation can be given the object
1691 location description as the object context or initial stack context to compute a
1692 component of the object. The final result is undefined if the object location
1693 description becomes invalid between the two expression evaluations.</i>
1697 location description, or using it as the object context or initial stack context
1701 holds the intended program object after a program location change. One way to
1708 of an opcode followed by zero or more operands. The number of operands is
1709 implied by the opcode.
1713 entries on the stack, including adding entries and removing entries. If the kind
1714 of a stack entry does not match the kind required by the operation and is not
1715 implicitly convertible to the required kind
1717 then the DWARF operation expression is ill-formed.
1719 Evaluation of an operation expression starts with an empty stack on which the
1720 entries from the initial stack provided by the context are pushed in the order
1721 provided. Then the operations are evaluated, starting with the first operation
1722 of the stream. Evaluation continues until either an operation has an evaluation
1723 error, or until one past the last operation of the stream is reached.
1725 The result of the evaluation is:
1728   expression that has an evaluation error, then the result is an evaluation
1730 - If the current result kind specifies a location description, then:
1731   - If the stack is empty, the result is a location description with one
1737   - If the top stack entry is a location description, or can be converted to one
1739     then the result is that, possibly converted, location description. Any other entries on the
1741   - Otherwise the DWARF expression is ill-formed.
1744     > as if the `DW_OP_implicit` operation is performed.
1746 - If the current result kind specifies a value, then:
1747   - If the top stack entry is a value, or can be converted to one (see
1749     then the result is that, possibly converted, value. Any other entries on the stack are
1751   - Otherwise the DWARF expression is ill-formed.
1752 - If the current result kind is not specified, then:
1753   - If the stack is empty, the result is a location description with one
1759     > NOTE: This rule is consistent with the rule above for when a location
1763   - Otherwise, the top stack entry is returned. Any other entries on the stack
1767 specifies the byte count. It can be used:
1769 - as the value of a debugging information entry attribute that is encoded using
1771 - as the operand to certain operation expression operations,
1772 - as the operand to certain call frame information operations (see [6.4 Call
1781 The following operations manipulate the DWARF stack. Operations that index the
1782 stack assume that the top of the stack (most recently added entry) has index 0.
1783 They allow the stack entries to be either a value or location description.
1787 (#composite-location-description-operations)), then the DWARF expression is ill-formed.
1793 > location descriptions, then would need to define that the composite location
1794 > storage specified by the incomplete composite location description is also
1795 > replicated when a copy is pushed. This ensures that each copy of the
1796 > incomplete composite location description can update the composite location
1801     `DW_OP_dup` duplicates the stack entry at the top of the stack.
1805     `DW_OP_drop` pops the stack entry at the top of the stack and discards it.
1810     I.  A copy of the stack entry with index I is pushed onto the stack.
1814     `DW_OP_over` pushes a copy of the entry with index 1.
1820     `DW_OP_swap` swaps the top two stack entries. The entry at the top of the
1821     stack becomes the second stack entry, and the second stack entry becomes the
1822     top of the stack.
1826     `DW_OP_rot` rotates the first three stack entries. The entry at the top of
1827     the stack becomes the third stack entry, the second entry becomes the top of
1828     the stack, and the third entry becomes the second entry.
1837 The following operations provide simple control of the flow of a DWARF operation
1842     `DW_OP_nop` is a place holder. It has no effect on the DWARF stack entries.
1847     > NOTE: The same as in DWARF Version 5 section 2.5.1.5.
1852     signed integer constant. The 2-byte constant is the number of bytes of the
1853     DWARF expression to skip forward or backward from the current operation,
1854     beginning after the 2-byte constant.
1856     If the updated position is at one past the end of the last operation, then
1857     the operation expression evaluation is complete.
1859     Otherwise, the DWARF expression is ill-formed if the updated operation
1860     position is not in the range of the first to last operation inclusive, or
1861     not at the start of an operation.
1866     integer constant. This operation pops the top of stack. If the value popped
1867     is not the constant 0, the 2-byte constant operand is the number of bytes of
1868     the DWARF operation expression to skip forward or backward from the current
1869     operation, beginning after the 2-byte constant.
1871     If the updated position is at one past the end of the last operation, then
1872     the operation expression evaluation is complete.
1874     Otherwise, the DWARF expression is ill-formed if the updated operation
1875     position is not in the range of the first to last operation inclusive, or
1876     not at the start of an operation.
1884     2-byte or 4-byte unsigned offset DR that represents the byte offset of a
1885     debugging information entry D relative to the beginning of the current
1888     `DW_OP_call_ref` has one operand that is a 4-byte unsigned value in the
1889     32-bit DWARF format, or an 8-byte unsigned value in the 64-bit DWARF format,
1890     that represents the byte offset DR of a debugging information entry D
1891     relative to the beginning of the `.debug_info` section that contains the
1892     current compilation unit. D may not be in the current compilation unit.
1895     > section other than the one that contains the current compilation unit. It
1897     > file to another must be performed by the consumer. But given that DR is
1899     > DR was defined as an implementation defined value, then the consumer could
1900     > choose to interpret the value in an implementation defined manner to
1903     > In ELF the `.debug_info` section is in a non-`PT_LOAD` segment so standard
1905     > and dynamic relocations were used, DR would need to be the address of D,
1907     > the size of a global address. So it would not be possible to use the
1908     > 32-bit DWARF format in a 64-bit global address space. In addition, the
1909     > consumer would need to determine what executable or shared object the
1910     > relocated address was in so it could determine the containing compilation
1913     > GDB only interprets DR as an offset in the `.debug_info` section that
1914     > contains the current compilation unit.
1922     The call operation is evaluated by:
1925       specifies an operation expression E, then execution of the current
1926       operation expression continues from the first operation of E. Execution
1927       continues until one past the last operation of E is reached, at which
1928       point execution continues with the operation following the call operation.
1929       The operations of E are evaluated with the same current context, except
1930       current compilation unit is the one that contains D and the stack is the
1931       same as that being used by the call operation. After the call operation
1932       has been evaluated, the stack is therefore as it is left by the evaluation
1933       of the operations of E. Since E is evaluated on the same stack as the call
1934       operation, E can use, and/or remove entries already on the stack, and can
1935       add new entries to the stack.
1937       <i>Values on the stack at the time of the call may be used as parameters
1938       by the called expression and values left on the stack by the called
1939       expression may be used as return values by prior agreement between the
1943       `loclistsptr`, then the specified location list expression E is evaluated.
1944       The evaluation of E uses the current context, except the result kind is a
1945       location description, the compilation unit is the one that contains D, and
1946       the initial stack is empty. The location description result is pushed on
1947       the stack.
1950       > location list entry operation expression on the same stack as the call
1951       > when there are multiple matches. But it allows the call to obtain the
1955       > An alternative is to treat the case when D has a `DW_AT_location`
1956       > attribute that is encoded as a `loclist` or `loclistsptr`, and the
1958       > entry with operation expression E, the same as the `exprloc` case and
1959       > evaluate on the same stack.
1961       > But this is not attractive as if the attribute is for a variable that
1963       > location description on the stack. Presumably the intent of using
1965       > entry is to push just one location description on the stack. That
1968       > The previous rule for `exprloc` also has the same problem, as normally a
1970       > entries on the stack and only return the top entry.
1972       > GDB implements `DW_OP_call*` by always executing E on the same stack. If
1973       > the location list has multiple matching entries, it simply picks the
1974       > first one and ignores the rest. This seems fundamentally at odds with
1975       > the desire to support multiple places for variables.
1978       > description on the stack for a variable or formal parameter, and also
1979       > support being able to execute an operation expression on the same stack.
1983       > A solution to that is to have a distinct `DW_AT_proc` attribute for the
1984       > `DW_TAG_dwarf_procedure` debugging information entry. Then the
1987       > descriptions), and the `DW_AT_proc` attribute expression is always
1988       > executed on the same stack and can leave anything on the stack.
1990       > The `DW_AT_proc` attribute could have the new classes `exprproc`,
1991       > `loclistproc`, and `loclistsptrproc` to indicate that the expression is
1992       > executed on the same stack. `exprproc` is the same encoding as
1993       > `exprloc`. `loclistproc` and `loclistsptrproc` are the same encoding as
1994       > their non-`proc` counterparts, except the DWARF is ill-formed if the
1996       > default entry is required. These forms indicate explicitly that the
1997       > matched single operation expression must be executed on the same stack.
2000       > location description. The producer then explicitly indicates the intent
2001       > through the attribute classes.
2004       > `DW_OP_call*`. However, are the breaking cases actually occurring in
2005       > practice? GDB could implement the current approach for DWARF Version 5,
2006       > and the new semantics for DWARF Version 6 which has been done for some
2009       > Another option is to limit the execution to be on the same stack only to
2010       > the evaluation of an expression E that is the value of a
2012       > information entry. The DWARF would be ill-formed if E is a location list
2014       > other cases the evaluation of an expression E that is the value of a
2015       > `DW_AT_location` attribute would evaluate E with the current context,
2016       > except the result kind is a location description, the compilation unit
2017       > is the one that contains D, and the initial stack is empty. The location
2018       > description result is pushed on the stack.
2023       <i>This allows a call operation to be used to compute the location
2024       description for any variable or formal parameter regardless of whether the
2025       producer has optimized it to a constant. This is consistent with the
2034     - Otherwise, there is no effect and no changes are made to the stack.
2038       > the right definition as a producer should be able to rely on using
2040       > non-`DW_TAG_dwarf_procedure` debugging information entries. Also, the
2046     <i>The `DW_TAG_dwarf_procedure` debugging information entry can be used to
2051 This section describes the operations that push values on the stack.
2054 literal value of any supported base type of the target architecture. The base
2055 type specifies the size, encoding, and endianity of the literal value.
2057 The base type of value stack entries can be the distinguished generic type.
2063 The following operations all push a literal value onto the DWARF stack.
2065 Operations other than `DW_OP_const_type` push a value V with the generic type.
2066 If V is larger than the generic type, then V is truncated to the generic type
2067 size and the low-order bits used.
2072     31, inclusive. They push the value N with the generic type.
2077     8-byte unsigned integer constant U, respectively. They push the value U with
2078     the generic type.
2083     8-byte signed integer constant S, respectively. They push the value S with
2084     the generic type.
2088     `DW_OP_constu` has a single unsigned LEB128 integer operand N. It pushes the
2089     value N with the generic type.
2093     `DW_OP_consts` has a single signed LEB128 integer operand N. It pushes the
2094     value N with the generic type.
2099     a zero-based index into the `.debug_addr` section relative to the value of
2100     the `DW_AT_addr_base` attribute of the associated compilation unit. The
2101     value N in the `.debug_addr` section has the size of the generic type. It
2102     pushes the value N with the generic type.
2104     <i>The `DW_OP_constx` operation is provided for constants that require
2105     link-time relocation but should not be interpreted by the consumer as a
2110     `DW_OP_const_type` has three operands. The first is an unsigned LEB128
2111     integer DR that represents the byte offset of a debugging information entry
2112     D relative to the beginning of the current compilation unit, that provides
2113     the type T of the constant value. The second is a 1-byte unsigned integral
2114     constant S. The third is a block of bytes B, with a length equal to S.
2116     TS is the bit size of the type T. The least significant TS bits of B are
2117     interpreted as a value V of the type D. It pushes the value V with the type
2120     The DWARF is ill-formed if D is not a `DW_TAG_base_type` debugging
2121     information entry in the current compilation unit, or if TS divided by 8
2122     (the byte size) and rounded up to a whole number is not equal to S.
2124     <i>While the size of the byte block B can be inferred from the type D
2125     definition, it is encoded explicitly into the operation so that the
2126     operation can be parsed easily without reference to the `.debug_info`
2131 > NOTE: This section is the same as DWARF Version 5 section 2.5.1.4.
2135 > NOTE: This section is the same as DWARF Version 5 section 2.5.1.6.
2146     `DW_OP_regval_type` has two operands. The first is an unsigned LEB128
2147     integer that represents a register number R. The second is an unsigned
2148     LEB128 integer DR that represents the byte offset of a debugging information
2149     entry D relative to the beginning of the current compilation unit, that
2150     provides the type T of the register value.
2152     The operation is equivalent to performing `DW_OP_regx R; DW_OP_deref_type
2155     > NOTE: Should DWARF allow the type T to be a larger size than the size of
2156     > the register R? Restricting a larger bit size avoids any issue of
2157     > conversion as the, possibly truncated, bit contents of the register is
2163     > Removing use of the target hook does not cause any test failures in common
2164     > architectures. If the compiler for a target architecture did want some
2166     > explicitly use the `DW_OP_convert` operation.
2168     > If T is a larger type than the register size, then the default GDB
2169     > register hook reads bytes from the next register (or reads out of bounds
2170     > for the last register!). Removing use of the target hook does not cause
2178     S is the bit size of the generic type divided by 8 (the byte size) and
2179     rounded up to a whole number. DR is the offset of a hypothetical debug
2180     information entry D in the current compilation unit for a base type of the
2183     The operation is equivalent to performing `DW_OP_deref_type S, DR`.
2190     TS is the smaller of the generic type bit size and S scaled by 8 (the byte
2191     size). If TS is smaller than the generic type bit size then T is an unsigned
2192     integral type of bit size TS, otherwise T is the generic type. DR is the
2193     offset of a hypothetical debug information entry D in the current
2196     > NOTE: Truncating the value when S is larger than the generic type matches
2197     > what GDB does. This allows the generic type size to not be an integral
2199     > to the size of the generic type rounded up to a multiple of 8?
2201     The operation is equivalent to performing `DW_OP_deref_type S, DR`, except
2202     if T is not the generic type, the value V pushed is zero-extended to the
2203     generic type bit size and its type changed to the generic type.
2207     `DW_OP_deref_type` has two operands. The first is a 1-byte unsigned integral
2208     constant S. The second is an unsigned LEB128 integer DR that represents the
2209     byte offset of a debugging information entry D relative to the beginning of
2210     the current compilation unit, that provides the type T of the result value.
2212     TS is the bit size of the type T.
2214     <i>While the size of the pushed value V can be inferred from the type T, it
2215     is encoded explicitly as the operand S so that the operation can be parsed
2216     easily without reference to the `.debug_info` section.</i>
2218     > NOTE: It is unclear why the operand S is needed. Unlike
2219     > `DW_OP_const_type`, the size is not needed for parsing. Any evaluation
2220     > needs to get the base type T to push with the value to know its encoding
2225     A value V of TS bits is retrieved from the location storage LS specified by
2226     one of the single location descriptions SL of L.
2228     <i>If L, or the location description of any composite location description
2231     all have the same value. For any single location description SL, bits are
2232     retrieved from the associated storage location starting at the bit offset
2233     specified by SL. For a composite location description, the retrieved bits
2234     are the concatenation of the N bits from each composite location part PL,
2235     where N is limited to the size of PL.</i>
2237     V is pushed on the stack with the type T.
2240     > location description that has less than TS bits remaining in the register
2243     > extension based on the type, or be target architecture dependent, as the
2244     > number of remaining bits could be any number. This matches the GDB
2249     > bit offset, and `DW_OP_deref_type`. Therefore, it requires the register
2250     > size to be greater or equal to the address size of the address space. This
2251     > matches the GDB implementation for `DW_OP_*breg*`.
2253     The DWARF is ill-formed if D is not in the current compilation unit, D is
2255     (the byte size) and rounded up to a whole number is not equal to S.
2257     > NOTE: This definition allows the base type to be a bit size since there
2260     It is an evaluation error if any bit of the value is retrieved from the
2261     undefined location storage or the offset of any bit exceeds the size of the
2265     for special rules concerning implicit location descriptions created by the
2270     `DW_OP_xderef` pops two stack entries. The first must be an integral type
2271     value that represents an address A. The second must be an integral type
2275     The address size S is defined as the address bit size of the target
2279     the least significant S bits as an unsigned value A'.
2282     SL specifies the memory location storage LS that corresponds to AS with a
2283     bit offset equal to A' scaled by 8 (the byte size).
2286     corresponds to the location storage associated with the current context.
2288     <i>For example, if AS is for per thread storage then LS is the location
2289     storage for the current thread. Therefore, if L is accessed by an operation,
2290     the location storage selected when the location description was created is
2291     accessed, and not the location storage associated with the current context
2292     of the access operation.</i>
2294     The DWARF expression is ill-formed if AS is not one of the values defined by
2295     the target architecture specific `DW_ASPACE_*` values.
2297     The operation is equivalent to popping A and AS, pushing L, and then
2298     performing `DW_OP_deref`. The value V retrieved is left on the stack with
2299     the generic type.
2306     It pops two stack entries. The first must be an integral type value
2307     that represents an address A. The second must be an integral type
2313     The operation is equivalent to popping A and AS, pushing L, and then
2314     performing `DW_OP_deref_size S` . The zero-extended value V retrieved is
2315     left on the stack with the generic type.
2319     `DW_OP_xderef_type` has two operands. The first is a 1-byte unsigned
2320     integral constant S. The second operand is an unsigned LEB128 integer DR
2321     that represents the byte offset of a debugging information entry D relative
2322     to the beginning of the current compilation unit, that provides the type T
2323     of the result value.
2325     It pops two stack entries. The first must be an integral type value that
2326     represents an address A. The second must be an integral type value that
2331     The operation is equivalent to popping A and AS, pushing L, and then
2332     performing `DW_OP_deref_type DR` . The value V retrieved is left on the
2333     stack with the type T.
2337     `DW_OP_entry_value` pushes the value of an expression that is evaluated in
2338     the context of the calling frame.
2340     <i>It may be used to determine the value of arguments on entry to the
2343     It has two operands. The first is an unsigned LEB128 integer S. The second
2347     E is evaluated with the current context, except the result kind is
2348     unspecified, the call frame is the one that called the current frame, the
2349     program location is the call site in the calling frame, the object is
2350     unspecified, and the initial stack is empty. The calling frame information
2351     is obtained by virtually unwinding the current call frame using the call
2355     If the result of E is a location description L (see [2.5.4.4.4 Register
2357     Operations](#register-location-description-operations)), and the last
2359     architecture specific base type of T, then the contents of the register are
2361     the offset of a hypothetical debug information entry in the current
2362     compilation unit for T. The resulting value V is pushed on the stack.
2364     <i>Using `DW_OP_reg*` provides a more compact form for the case where the
2365     value was in a register on entry to the subprogram.</i>
2370     If the result of E is a value V, then V is pushed on the stack.
2372     Otherwise, the DWARF expression is ill-formed.
2374     <i>The `DW_OP_entry_value` operation is deprecated as its main usage is
2375     provided by other means. DWARF Version 5 added the
2379     actual parameter values at the time of the call, and requires the producer
2380     to ensure the expressions are valid to evaluate even when virtually
2388 This section describes the operations that push location descriptions on the
2397     `DW_OP_push_object_address` pushes the location description L of the current
2401     user presented expression that is being evaluated. The object location
2402     description may be determined from the variable's own debugging information
2408     involving descriptors) that is analogous to the implicit push of the base
2412     > NOTE: This operation could be removed and the object location description
2413     > specified as the initial stack as for `DW_AT_data_member_location`.
2416     > stack. The latter approach is more composable as access to the object may
2417     > be needed at any point of the expression, and passing it as the initial
2418     > stack requires the entire expression to be aware where on the stack it is.
2420     > ``DW_OP_push_object2_address`` operation for the second object.
2423     > operation to get the Nth one such as ``DW_OP_arg N``. A vector of
2424     > arguments would then be passed in the expression context rather than an
2425     > initial stack. This could also resolve the issues with ``DW_OP_call*`` by
2427     > specified. The ``DW_OP_call*`` operation could then always execute on a
2428     > separate stack: the number of arguments would be specified in a new call
2429     > operation and taken from the callers stack, and similarly the number of
2430     > return results specified and copied from the called stack back to the
2431     > callee stack when the called expression was complete.
2433     > The only attribute that specifies a current object is
2434     > `DW_AT_data_location` so the non-normative text seems to overstate how
2442 <i>The undefined location storage represents a piece or all of an object that is
2443 present in the source but not in the object code (perhaps due to optimization).
2444 Neither reading nor writing to the undefined location storage is meaningful.</i>
2446 An undefined location description specifies the undefined location storage.
2447 There is no concept of the size of the undefined location storage, nor of a bit
2448 offset for an undefined location description. The `DW_OP_*piece` operations can
2457 Each of the target architecture specific address spaces has a corresponding
2458 memory location storage that denotes the linear addressable memory of that
2459 address space. The size of each memory location storage corresponds to the range
2460 of the addresses in the corresponding address space.
2464 memory, or more than one location storage may alias the same physical memory
2465 possibly at different offsets and with different interleaving. The mapping may
2466 also be dictated by the source language address classes.</i>
2468 A memory location description specifies a memory location storage. The bit
2469 offset corresponds to a bit position within a byte of the memory. Bits accessed
2470 using a memory location description, access the corresponding target
2471 architecture memory starting at the bit position within the byte specified by
2472 the bit offset.
2474 A memory location description that has a bit offset that is a multiple of 8 (the
2476 memory byte address A that is equal to the bit offset divided by 8.
2479 of 8 (the byte size) is defined to be a bit field memory location description.
2480 It has a bit position B equal to the bit offset modulo 8, and a memory byte
2481 address A equal to the bit offset minus B that is then divided by 8.
2483 The address space AS of a memory location description is defined to be the
2484 address space that corresponds to the memory location storage associated with
2485 the memory location description.
2489 has a byte address equal to A and an address space equal to AS of the
2492 `DW_ASPACE_none` is defined as the target architecture default address space.
2495 with the generic type, then it is implicitly converted to a location description
2496 L with one memory location description SL. SL specifies the memory location
2497 storage that corresponds to the target architecture default address space with a
2498 bit offset equal to V scaled by 8 (the byte size).
2501 > converted to a memory location description in the target architecture default
2506 > > description L with a one memory location description SL. If the type size of
2507 > > V is less than the generic type size, then the value V is zero extended to
2508 > > the size of the generic type. The least significant generic type size bits
2510 > > memory location storage corresponding to the target architecture default
2511 > > address space with a bit offset equal to A scaled by 8 (the byte size).
2513 > The implicit conversion could also be defined as target architecture specific.
2515 > error. Otherwise, GDB zero-extends V to 64 bits. If the GDB target defines a
2516 > hook function, then it is called. The target specific hook function can modify
2517 > the 64-bit value, possibly sign extending based on the original value type.
2518 > Finally, GDB treats the 64-bit value V as a memory location address.
2521 pointer value IPV with the target architecture default address space, then it is
2527 with one memory location description SL in the target architecture default
2529 converted to a value equal to B divided by 8 (the byte size) with the generic
2534     `DW_OP_addr` has a single byte constant value operand, which has the size of
2535     the generic type, that represents an address A.
2538     on the stack. SL specifies the memory location storage corresponding to the
2540     scaled by 8 (the byte size).
2542     <i>If the DWARF is part of a code object, then A may need to be relocated.
2543     For example, in the ELF code object format, A must be adjusted by the
2544     difference between the ELF segment virtual address and the virtual address
2545     at which the segment is loaded.</i>
2550     zero-based index into the `.debug_addr` section relative to the value of the
2551     `DW_AT_addr_base` attribute of the associated compilation unit. The address
2552     value A in the `.debug_addr` section has the size of the generic type.
2555     on the stack. SL specifies the memory location storage corresponding to the
2557     scaled by 8 (the byte size).
2559     <i>If the DWARF is part of a code object, then A may need to be relocated.
2560     For example, in the ELF code object format, A must be adjusted by the
2561     difference between the ELF segment virtual address and the virtual address
2562     at which the segment is loaded.</i>
2570     on the stack. SL is the target architecture specific memory location
2571     description that corresponds to the thread-local storage address TA.
2573     The meaning of the thread-local storage address TA is defined by the
2574     run-time environment. If the run-time environment supports multiple
2575     thread-local storage blocks for a single thread, then the block
2576     corresponding to the executable or shared library containing this DWARF
2584     declared in the main executable, and a separate block for the variables
2587     byte offset into the block and pushed onto the DWARF stack by one of the
2588     `DW_OP_const*` operations prior to the `DW_OP_form_tls_address` operation.
2589     Computing the address of the appropriate block can be complex (in some
2590     cases, the compiler emits a function call to do it), and difficult to
2592     complex thread-local storage calculations into the DWARF expressions, the
2593     `DW_OP_form_tls_address` allows the consumer to perform the computation
2594     based on the target architecture specific run-time environment.</i>
2598     `DW_OP_call_frame_cfa` pushes the location description L of the Canonical
2599     Frame Address (CFA) of the current subprogram, obtained from the call frame
2600     information on the stack. See [6.4 Call Frame
2603     <i>Although the value of the `DW_AT_frame_base` attribute of the debugger
2604     information entry corresponding to the current subprogram can be computed
2606     extensive location list because the values of the registers used in
2607     computing the CFA change during a subprogram execution. If the call frame
2609     space efficient to reference that using the `DW_OP_call_frame_cfa`
2617     The location description L for the <i>frame base</i> of the current
2618     subprogram is obtained from the `DW_AT_frame_base` attribute of the debugger
2619     information entry corresponding to the current subprogram as described in
2622     The location description L is updated by bit offset B scaled by 8 (the byte
2623     size) and pushed on the stack.
2627     The `DW_OP_breg<N>` operations encode the numbers of up to 32 registers,
2628     numbered from 0 through 31, inclusive. The register number R corresponds to
2629     the N in the operation name.
2634     The address space identifier AS is defined as the one corresponding to the
2637     The address size S is defined as the address bit size of the target
2640     The contents of the register specified by R are retrieved as if a
2641     `DW_OP_regval_type R, DR` operation was performed where DR is the offset of
2642     a hypothetical debug information entry in the current compilation unit for
2643     an unsigned integral base type of size S bits. B is added and the least
2648     description LS on the stack. LS specifies the memory location storage that
2649     corresponds to AS with a bit offset equal to A scaled by 8 (the byte size).
2653     `DW_OP_bregx` has two operands. The first is an unsigned LEB128 integer that
2654     represents a register number R. The second is a signed LEB128 integer that
2657     The action is the same as for `DW_OP_breg<N>`, except that R is used as the
2658     register number and B is used as the byte displacement.
2664 There is a register location storage that corresponds to each of the target
2665 architecture registers. The size of each register location storage corresponds
2666 to the size of the corresponding target architecture register.
2668 A register location description specifies a register location storage. The bit
2669 offset corresponds to a bit position within the register. Bits accessed using a
2670 register location description access the corresponding target architecture
2671 register starting at the specified bit offset.
2675     `DW_OP_reg<N>` operations encode the numbers of up to 32 registers, numbered
2676     from 0 through 31, inclusive. The target architecture register number R
2677     corresponds to the N in the operation name.
2679     The operation is equivalent to performing `DW_OP_regx R`.
2686     If the current call frame is the top call frame, it pushes a location
2687     description L that specifies one register location description SL on the
2688     stack. SL specifies the register location storage that corresponds to R with
2689     a bit offset of 0 for the current thread.
2691     If the current call frame is not the top call frame, call frame information
2693     determine the location description that holds the register for the current
2694     call frame and current program location of the current thread. The resulting
2697     <i>Note that if call frame information is used, the resulting location
2700     <i>An implementation may evaluate the call frame information immediately, or
2702     deferred, R and the current context can be recorded in L. When accessed, the
2703     recorded context is used to evaluate the call frame information, not the
2704     current context of the access operation.</i>
2706 <i>These operations obtain a register location. To fetch the contents of a
2707 register, it is necessary to use `DW_OP_regval_type`, use one of the
2716 actual location in the program but whose contents are nonetheless known, either
2717 as a constant or can be computed from other locations and values in the program.
2719 An implicit location description specifies an implicit location storage. The bit
2720 offset corresponds to a bit position within the implicit location storage. Bits
2721 accessed using an implicit location description, access the corresponding
2722 implicit storage value starting at the bit offset.
2726     `DW_OP_implicit_value` has two operands. The first is an unsigned LEB128
2727     integer that represents a byte size S. The second is a block of bytes with a
2730     An implicit location storage LS is created with the literal value V and a
2734     on the stack. SL specifies LS with a bit offset of 0.
2740     An implicit location storage LS is created with the literal value V using
2741     the size, encoding, and endianity specified by V's base type.
2744     on the stack. SL specifies LS with a bit offset of 0.
2746     <i>The `DW_OP_stack_value` operation specifies that the object does not
2747     exist in memory, but its value is nonetheless known. In this form, the
2748     location description specifies the actual value of the object, rather than
2749     specifying the memory or register storage that holds the value.</i>
2753     descriptions created by the `DW_OP_implicit_pointer` operation.
2755     Note: Since location descriptions are allowed on the stack, the
2756     `DW_OP_stack_value` operation no longer terminates the DWARF operation
2761     <i>An optimizing compiler may eliminate a pointer, while still retaining the
2762     value that the pointer addressed. `DW_OP_implicit_pointer` allows a producer
2765     <i>`DW_OP_implicit_pointer` specifies an object is a pointer to the target
2767     pointer, even though the value it would point to can be described. In this
2768     form, the location description specifies a debugging information entry that
2769     represents the actual location description of the object to which the
2770     pointer would point. Thus, a consumer of the debug information would be able
2771     to access the dereferenced pointer, even when it cannot access the pointer
2774     `DW_OP_implicit_pointer` has two operands. The first operand is a 4-byte
2775     unsigned value in the 32-bit DWARF format, or an 8-byte unsigned value in
2776     the 64-bit DWARF format, that represents the byte offset DR of a debugging
2777     information entry D relative to the beginning of the `.debug_info` section
2778     that contains the current compilation unit. The second operand is a signed
2781     <i>Note that D might not be in the current compilation unit.</i>
2783     <i>The first operand interpretation is exactly like that for
2786     The address space identifier AS is defined as the one corresponding to the
2789     The address size S is defined as the address bit size of the target
2792     An implicit location storage LS is created with the debugging information
2796     description SL on the stack. SL specifies LS with a bit offset of 0.
2800     an implicit location storage that is the same as LS, unless both the
2804         refers to an implicit location storage that is the same as LS.
2806         <i>Note that all bits do not have to come from the same implicit
2810     2.  The bits come from consecutive ascending offsets within their respective
2813     <i>These rules are equivalent to retrieving the complete contents of LS.</i>
2815     If both the above conditions are met, then the value V pushed by the
2818     D, and a base type of T. If AS is the target architecture default address
2819     space, then T is the generic type. Otherwise, T is a target architecture
2823     if AS is the target architecture default address space), then the resulting
2826     - If D has a `DW_AT_location` attribute, the DWARF expression E from the
2827       `DW_AT_location` attribute is evaluated with the current context, except
2828       that the result kind is a location description, the compilation unit is
2829       the one that contains D, the object is unspecified, and the initial stack
2830       is empty. RL is the expression result.
2832       <i>Note that E is evaluated with the context of the expression accessing
2833       IPV, and not the context of the expression that contained the
2837       storage RLS is created from the `DW_AT_const_value` attribute's value with
2838       a size matching the size of the `DW_AT_const_value` attribute's value. RL
2848     The location description RL is updated by bit offset B scaled by 8 (the byte
2851     If a `DW_OP_stack_value` operation pops a value that is the same as IPV,
2852     then it pushes a location description that is the same as L.
2856     <i>The restrictions on how an implicit pointer location description created
2857     by `DW_OP_implicit_pointer` can be used are to simplify the DWARF consumer.
2863 information entry D<sub>1</sub>'s `DW_AT_location` attribute. The debugging
2864 information entry referenced by the `DW_OP_implicit_pointer` operation is
2869 <i>D<sub>1</sub> and E<sub>1</sub> are describing the location of a pointer type
2870 object. D<sub>2</sub> and E<sub>2</sub> are describing the location of the
2876 the value of the object when asked to dereference the pointer described by
2877 E<sub>1</sub> which contains the `DW_OP_implicit_pointer` operation.</i>
2889 that indicates that part is located in more than one place. The bits of each
2890 place of the part comprise S contiguous bits from the location storage LS
2891 specified by SL starting at the bit offset specified by SL. All the bits must be
2892 within the size of LS or the DWARF expression is ill-formed.
2894 A composite location storage can have zero or more parts. The parts are
2895 contiguous such that the zero-based location storage bit index will range over
2896 each part with no gaps between them. Therefore, the size of a composite location
2897 storage is the sum of the size of its parts. The DWARF expression is ill-formed
2898 if the size of the contiguous location storage is larger than the size of the
2899 memory location storage corresponding to the largest target architecture
2902 A composite location description specifies a composite location storage. The bit
2903 offset corresponds to a bit position within the composite location storage.
2909 be one or more operations to create the final composite location storage. A
2910 series of such operations describes the parts of the composite location storage
2911 that are in the order that the associated part operations are executed.
2922 If the top stack entry is a location description that has one incomplete
2923 composite location description SL after the execution of an operation expression
2926 <i>Note that this conversion does not happen after the completion of an
2927 operation expression that is evaluated on the same stack by the `DW_OP_call*`
2929 expression, but rather the continued evaluation of the same operation expression
2930 that contains the `DW_OP_call*` operation.</i>
2933 incomplete composite location description, then the DWARF expression is
2934 ill-formed. The exception is for the operations involved in incrementally
2942 <i>The incremental composite location description operations are defined to be
2943 compatible with the definitions in DWARF Version 5.</i>
2950     The action is based on the context:
2952     - If the stack is empty, then a location description L comprised of one
2953       incomplete composite location description SL is pushed on the stack.
2957       8 (the byte size). PL is comprised of one undefined location description
2962     - Otherwise, if the top stack entry is a location description L comprised of
2963       one incomplete composite location description SL, then the incomplete
2966       scaled by 8 (the byte size). PL is comprised of one undefined location
2967       description PSL. L is left on the stack.
2968     - Otherwise, if the top stack entry is a location description or can be
2972       - If the top stack entry (after popping PL) is a location description L
2973         comprised of one incomplete composite location description SL, then the
2975         append a new part P. P specifies the location description PL and has a
2976         bit size of S scaled by 8 (the byte size). L is left on the stack.
2979         the stack.
2982         part P. P specifies the location description PL and has a bit size of S
2983         scaled by 8 (the byte size).
2987     - Otherwise, the DWARF expression is ill-formed
2993     <i>The evaluation rules for the `DW_OP_piece` operation allow it to be
2994     compatible with the DWARF Version 5 definition.</i>
2997     > the stack, a simpler operation to create composite location descriptions
2999     > parts, and pops pairs of stack entries for the part size and location
3000     > description. Not only would this be a simpler operation and avoid the
3002     > also have a smaller encoding in practice. However, the desire for
3007     `DW_OP_bit_piece` has two operands. The first is an unsigned LEB128 integer
3008     that represents the part bit size S. The second is an unsigned LEB128
3011     The action is the same as for `DW_OP_piece`, except that any part created
3012     has the bit size S, and the location description PL of any created part is
3015     <i>`DW_OP_bit_piece` is used instead of `DW_OP_piece` when the piece to be
3016     assembled is not byte-sized or is not at the start of the part location
3023 <i>To meet the needs of recent computer architectures and optimization
3024 techniques, debugging information must be able to describe the location of an
3025 object whose location changes over the object's lifetime, and may reside at
3027 expressions are used in place of operation expressions whenever the object whose
3031 location list entry is one of the following kinds:
3036     evaluates to the location description of an object that is valid over a
3037     lifetime bounded by a starting and ending address. The starting address is
3038     the lowest address of the address range over which the location is valid.
3039     The ending address is the address of the first location past the highest
3040     address of the address range.
3042     The location list entry matches when the current program location is within
3043     the given range.
3046     in the way that they specify the starting and ending addresses.
3051     evaluates to the location description of an object that is valid when no
3054     The location list entry matches when the current program location is not
3055     within the range of any bounded location description entry.
3059     This kind of location list entry provides an address to be used as the base
3061     bounded location description entries. The applicable base address of a
3062     bounded location description entry is the address specified by the closest
3063     preceding base address entry in the same location list. If there is no
3064     preceding base address entry, then the applicable base address defaults to
3065     the base address of the compilation unit (see DWARF Version 5 section
3068     In the case of a compilation unit where all of the machine code is contained
3073     This kind of location list entry marks the end of the location list
3076 The address ranges defined by the bounded location description entries of a
3080 If all of the address ranges in a given location list expression do not
3081 collectively cover the entire range over which the object in question is
3083 assumed that the object is not available for the portion of the range that is
3086 The result of the evaluation of a DWARF location list expression is:
3088 - If the current program location is not specified, then it is an evaluation
3091   > NOTE: If the location list only has a single default entry, should that be
3094   > program location as that indicates the location depends on the program
3097 - If there are no matching location list entries, then the result is a location
3099 - Otherwise, the operation expression E of each matching location list entry is
3100   evaluated with the current context, except that the result kind is a location
3101   description, the object is unspecified, and the initial stack is empty. The
3102   location list entry result is the location description returned by the
3105   The result is a location description that is comprised of the union of the
3106   single location descriptions of the location description result of each
3109 A location list expression can only be used as the value of a debugger
3111 `loclistsptr` (see [7.5.5 Classes and Forms](#classes-and-forms)). The value of
3112 the attribute provides an index into a separate object file section called
3114 contains the location list entries.
3120 originate from the evaluation of a location list expression.
3122 <i>This location list representation, the `loclist` and `loclistsptr` class, and
3123 the related `DW_AT_loclists_base` attribute are new in DWARF Version 5. Together
3124 they eliminate most, or all of the code object relocations previously needed for
3127 > NOTE: The rest of this section is the same as DWARF Version 5 section 2.6.2.
3132 > attributes. These would be incorporated into the corresponding DWARF Version 5
3143     The result of the attribute is obtained by evaluating E with a context that
3144     has a result kind of a location description, an unspecified object, the
3146     elements corresponding to the source language thread of execution upon which
3147     the user is focused, if any. The result of the evaluation is the location
3148     description L of the place where the return address for the current call
3151     The DWARF is ill-formed if L is not comprised of one memory location
3152     description for one of the target architecture specific address spaces.
3163     The result of the attribute is obtained by evaluating E with a context that
3164     has a result kind of a location description, an unspecified object, the
3166     elements corresponding to the source language thread of execution upon which
3167     the user is focused, if any.
3169     The DWARF is ill-formed if E contains a `DW_OP_fbreg` operation, or the
3174     with the result of evaluating a `DW_OP_bregx R, 0` operation. This computes
3175     the frame base memory location description in the target architecture
3178     <i>This allows the more compact `DW_OP_reg*` to be used instead of
3181     > NOTE: This rule could be removed and require the producer to create the
3183     > `DW_OP_breg*`. This would also then allow a target to implement the call
3186     Otherwise, the DWARF is ill-formed if SL is not a memory location
3187     description in any of the target architecture specific address spaces.
3189     The resulting L is the <i>frame base</i> for the subprogram or entry point.
3191     <i>Typically, E will use the `DW_OP_call_frame_cfa` operation or be a stack
3198     The result of the attribute is obtained by evaluating E with a context that
3199     has a result kind of a location description, an unspecified object, the
3201     elements corresponding to the source language thread of execution upon which
3202     the user is focused, if any. The result of the evaluation is the location
3203     description L of the <i>canonical frame address</i> (see [6.4 Call Frame
3204     Information](#call-frame-information)) of the relevant call frame of the
3205     subprogram instance that immediately lexically encloses the current call
3208     The DWARF is ill-formed if L is is not comprised of one memory location
3209     description for one of the target architecture specific address spaces.
3219     The result of the `DW_AT_call_value` attribute is obtained by evaluating
3221     object, the compilation unit that contains E, an empty initial stack, and other
3222     context elements corresponding to the source language thread of execution upon
3223     which the user is focused, if any. The resulting value V<sub>1</sub> is the
3224     value of the parameter at the time of the call made by the call site.
3226     For parameters passed by reference, where the code passes a pointer to a
3227     location which contains the parameter, or for reference type parameters, the
3233     The value of the `DW_AT_call_data_location` attribute is obtained by evaluating
3235     an unspecified object, the compilation unit that contains E, an empty initial
3236     stack, and other context elements corresponding to the source language thread of
3237     execution upon which the user is focused, if any. The resulting location
3238     description L<sub>2</sub> is the location where the referenced parameter lives
3239     during the call made by the call site. If E<sub>2</sub> would just be a
3240     `DW_OP_push_object_address`, then the `DW_AT_call_data_location` attribute may
3243     > NOTE: The DWARF Version 5 implies that `DW_OP_push_object_address` may be
3244     > used but does not state what object must be specified in the context.
3245     > Either `DW_OP_push_object_address` cannot be used, or the object to be
3246     > passed in the context must be defined.
3248     The value of the `DW_AT_call_data_value` attribute is obtained by evaluating
3250     object, the compilation unit that contains E, an empty initial stack, and other
3251     context elements corresponding to the source language thread of execution upon
3252     which the user is focused, if any. The resulting value V<sub>3</sub> is the
3253     value in L<sub>2</sub> at the time of the call made by the call site.
3255     The result of these attributes is undefined if the current call frame is not for
3256     the subprogram containing the `DW_TAG_call_site_parameter` debugger information
3257     entry or the current program location is not for the call site containing the
3258     `DW_TAG_call_site_parameter` debugger information entry in the current call
3261     <i>The consumer may have to virtually unwind to the call site (see [6.4 Call
3263     attributes. This will ensure the source language thread of execution upon which
3264     the user is focused corresponds to the call site needed to evaluate the
3267     If it is not possible to avoid the expressions of these attributes from
3268     accessing registers or memory locations that might be clobbered by the
3269     subprogram being called by the call site, then the associated attribute should
3272     <i>The reason for the restriction is that the parameter may need to be accessed
3273     during the execution of the callee. The consumer may virtually unwind from the
3274     called subprogram back to the caller and then evaluate the attribute
3275     expressions. The call frame information (see [6.4 Call Frame
3277     that have been clobbered, and clobbered memory will no longer have the value at
3278     the time of the call.</i>
3282 > NOTE: This section is the same as DWARF Version 5 section 3.5.
3287 > attributes. These would be incorporated into the corresponding DWARF Version 5
3293 information entries with the tags `DW_TAG_variable`, `DW_TAG_formal_parameter`
3296 *The tag `DW_TAG_constant` is used for languages that have true named constants.*
3298 The debugging information entry for a program variable, formal parameter or
3299 constant may have the following attributes:
3302     describes the location of a variable or parameter at run-time.
3304     The result of the attribute is obtained by evaluating E with a context that
3305     has a result kind of a location description, an unspecified object, the
3307     elements corresponding to the source language thread of execution upon which
3308     the user is focused, if any. The result of the evaluation is the location
3309     description of the base of the data object.
3312     evaluation rules used by the `DW_OP_call*` operations.
3314     > NOTE: Delete the description of how the `DW_OP_call*` operations evaluate
3315     > a `DW_AT_location` attribute as that is now described in the operations.
3317     > NOTE: See the discussion about the `DW_AT_location` attribute in the
3319     > and single execution semantics seems desirable. It makes it easier for the
3320     > consumer that no longer have to track the context. It makes it easier for
3321     > the producer as it can rely on a single semantics for each attribute.
3323     > For that reason, limiting the `DW_AT_location` attribute to only
3324     > supporting evaluating the location description of an object, and using a
3325     > different attribute and encoding class for the evaluation of DWARF
3326     > expression <i>procedures</i> on the same operation expression stack seems
3331     > NOTE: Could deprecate using the `DW_AT_const_value` attribute for
3336     > expression. This allows the `DW_OP_call*` operations to be used to push
3337     > the location description of any variable regardless of how it is
3343 expression E that describes the location of the common block at run-time. The
3344 result of the attribute is obtained by evaluating E with a context that has a
3345 result kind of a location description, an unspecified object, the compilation
3347 corresponding to the source language thread of execution upon which the user is
3348 focused, if any. The result of the evaluation is the location description of the
3349 base of the common block. See 2.5.4.2 Control Flow Operations for special
3350 evaluation rules used by the DW_OP_call* operations.
3355 > attributes. These would be incorporated into the corresponding DWARF Version 5
3364     1.  If the attribute is an integer constant B, it provides the offset in
3365         bytes from the beginning of the containing entity.
3367         The result of the attribute is obtained by updating the bit offset of
3368         the location description of the beginning of the containing entity by B
3369         scaled by 8 (the byte size). The result is the location description of
3370         the base of the member entry.
3372         <i>If the beginning of the containing entity is not byte aligned, then
3373         the beginning of the member entry has the same bit displacement within a
3376     2.  Otherwise, the attribute must be a DWARF expression E which is evaluated
3378         unspecified object, the compilation unit that contains E, an initial
3379         stack comprising the location description of the beginning of the
3380         containing entity, and other context elements corresponding to the
3381         source language thread of execution upon which the user is focused, if
3382         any. The result of the evaluation is the location description of the
3383         base of the member entry.
3385     > NOTE: The beginning of the containing entity can now be any location
3395     The result of the attribute is obtained by evaluating E with a context that
3396     has a result kind of a location description, an unspecified object, the
3397     compilation unit that contains E, an initial stack comprising the location
3398     description of the object of the enclosing type, and other context elements
3399     corresponding to the source language thread of execution upon which the user
3400     is focused, if any. The result of the evaluation is the location description
3401     of the slot for the function within the virtual function table for the
3406 1.  The `DW_TAG_ptr_to_member_type` debugging information entry has a
3408     to compute the location description of the member of the class to which the
3411     <i>The method used to find the location description of a given member of a
3413     or union and to any instance of the pointer to member type. The method is thus
3414     associated with the pointer to member type, rather than with each object that
3417     The `DW_AT_use_location` DWARF expression is used in conjunction with the
3418     location description for a particular object of the given pointer to member type
3421     The result of the attribute is obtained by evaluating E with a context that has
3422     a result kind of a location description, an unspecified object, the compilation
3424     elements corresponding to the source language thread of execution upon which the
3425     user is focused, if any. The first stack entry is the value of the pointer to
3426     member object itself. The second stack entry is the location description of the
3427     base of the entire class, structure, or union instance containing the member
3428     whose location is being calculated. The result of the evaluation is the location
3429     description of the member of the class to which the pointer to member entry
3436 1.  The `DW_AT_data_location` attribute may be used with any type that provides one
3438     representation. Its value is a DWARF operation expression E which computes the
3439     location description of the data for an object. When this attribute is omitted,
3440     the location description of the data is the same as the location description of
3441     the object.
3443     The result of the attribute is obtained by evaluating E with a context that has
3444     a result kind of a location description, an object that is the location
3445     description of the data descriptor, the compilation unit that contains E, an
3446     empty initial stack, and other context elements corresponding to the source
3447     language thread of execution upon which the user is focused, if any. The result
3448     of the evaluation is the location description of the base of the member entry.
3451     `DW_OP_push_object_address` operation which loads the location description
3452     of the object which can then serve as a descriptor in subsequent
3462     > It seems odd this attribute is not the same as `DW_AT_data_member_location` in
3463     > having an initial stack with the location description of the object since the
3469 > attributes. These would be incorporated into the corresponding DWARF Version 5
3474 > NOTE: This section is the same as DWARF Version 5 section 6.2.
3484 The register rules are:
3488     A register that has this rule has no recoverable value in the previous
3489     frame. The previous value of this register is the undefined location
3493     <i>By convention, the register is not preserved by a callee.</i>
3497     This register has not been modified from the previous caller frame.
3499     If the current frame is the top frame, then the previous value of this
3500     register is the location description L that specifies one register location
3501     description SL. SL specifies the register location storage that corresponds
3502     to the register with a bit offset of 0 for the current thread.
3504     If the current frame is not the top frame, then the previous value of this
3505     register is the location description obtained using the call frame
3506     information for the callee frame and callee program location invoked by the
3507     current caller frame for the same register.
3509     <i>By convention, the register is preserved by the callee, but the callee
3514     N is a signed byte offset. The previous value of this register is saved at
3515     the location description L. Where L is the location description of the
3517     Expressions](#dwarf-operation-expressions)) updated with the bit offset N
3518     scaled by 8 (the byte size).
3522     N is a signed byte offset. The previous value of this register is the memory
3523     byte address of the location description L. Where L is the location
3524     description of the current CFA (see [2.5.4 DWARF Operation
3525     Expressions](#dwarf-operation-expressions)) updated with the bit offset N
3526     scaled by 8 (the byte size).
3528     The DWARF is ill-formed if the CFA location description is not a memory byte
3529     address location description, or if the register size does not match the
3530     size of an address in the target architecture default address space.
3532     <i>Since the CFA location description is required to be a memory byte
3533     address location description, the value of val_offset(N) will also be a
3534     memory byte address location description since it is offsetting the CFA
3535     location description by N bytes. Furthermore, the value of val_offset(N)
3536     will be a memory byte address in the target architecture default address
3539     > NOTE: Should DWARF allow the address size to be a different size to the
3540     > size of the register? Requiring them to be the same bit size avoids any
3541     > issue of conversion as the bit contents of the register is simply
3542     > interpreted as a value of the address.
3546     > and to actually reading bytes from the next register (or reads out of
3547     > bounds for the last register) for smaller registers. There are no GDB
3555     The previous value of this register is the location description obtained
3556     using the call frame information for the current frame and current program
3559     The DWARF is ill-formed if the size of this register does not match the size
3560     of register R or if there is a cyclic dependency in the call frame
3564     > the value stored in the low order bits and it is undefined what is stored
3565     > in the extra upper bits?
3569     The previous value of this register is located at the location description
3570     produced by evaluating the DWARF operation expression E (see [2.5.4 DWARF
3573     E is evaluated with the current context, except the result kind is a
3574     location description, the compilation unit is unspecified, the object is
3575     unspecified, and an initial stack comprising the location description of the
3581     The previous value of this register is located at the implicit location
3582     description created from the value produced by evaluating the DWARF
3586     E is evaluated with the current context, except the result kind is a value,
3587     the compilation unit is unspecified, the object is unspecified, and an
3588     initial stack comprising the location description of the current CFA (see
3591     The DWARF is ill-formed if the resulting value type size does not match the
3594     > NOTE: This has limited usefulness as the DWARF expression E can only
3595     > produce values up to the size of the generic type. This is due to not
3597     > This makes it unusable for registers that are larger than the generic
3603     The rule is defined externally to this specification by the augmenter.
3607 `.debug_frame` section. A CIE contains the following fields, in order:
3611     A constant that gives the number of bytes of the CIE structure, not
3612     including the length field itself. The size of the length field plus the
3613     value of length must be an integral multiple of the address size specified
3614     in the `address_size` field.
3620     In the 32-bit DWARF format, the value of the CIE id in the CIE header is
3621     0xffffffff; in the 64-bit DWARF format, the value is 0xffffffffffffffff.
3625     A version number. This number is specific to the call frame information and
3626     is independent of the DWARF version number.
3628     The value of the CIE version number is 4.
3630     > NOTE: Would this be increased to 5 to reflect the changes in these
3635     A null-terminated UTF-8 string that identifies the augmentation to this CIE
3636     or to the FDEs that use it. If a reader encounters an augmentation string
3637     that is unexpected, then only the following fields can be read:
3644     <i>The augmentation string allows users to indicate that there is additional
3645     vendor and target architecture specific information in the CIE or FDE which
3648     from the routine.</i>
3650     <i>Because the `.debug_frame` section is useful independently of any
3651     `.debug_info` section, the augmentation string always uses UTF-8
3656     The size of a target address in this CIE and any FDEs that use it, in bytes.
3657     If a compilation unit exists for this frame, its address size must match the
3662     The size of a segment selector in this CIE and any FDEs that use it, in
3668     [6.4.2.1 Row Creation Instructions](#row-creation-instructions)). The
3675     Register Rule Instructions](#register-rule-instructions)). The
3680     An unsigned LEB128 constant that indicates which column in the rule table
3681     represents the return address of the subprogram. Note that this column might
3684     The value of the return address register is used to determine the program
3685     location of the caller frame. The program location of the top frame is the
3686     target architecture program counter value of the current thread.
3690     A sequence of rules that are interpreted to create the initial setting of
3691     each column in the table.
3693     The default rule for all columns before interpretation of the initial
3694     instructions is the undefined rule. However, an ABI authoring body or a
3700     Enough `DW_CFA_nop` instructions to make the size of this entry match the
3703 An FDE contains the following fields, in order:
3707     A constant that gives the number of bytes of the header and instruction
3708     stream for this subprogram, not including the length field itself. The size
3709     of the length field plus the value of length must be an integral multiple of
3710     the address size.
3714     A constant offset into the `.debug_frame` section that denotes the CIE that
3719     The address of the first location associated with this table entry. If the
3720     segment_selector_size field of this FDE's CIE is non-zero, the initial
3721     location is preceded by a segment selector of the given length.
3725     The number of bytes of program instructions described by this entry.
3734     Enough `DW_CFA_nop` instructions to make the size of this entry match the
3741 Expressions](#dwarf-operation-expressions)). The DWARF operations that can be
3742 used in E have the following restrictions:
3748   because the call frame information must not depend on other debug sections.
3760 > NOTE: These instructions are the same as in DWARF Version 5 section 6.4.2.1.
3766     The `DW_CFA_def_cfa` instruction takes two unsigned LEB128 operands
3768     The required action is to define the current CFA rule to be equivalent to
3769     the result of evaluating the DWARF operation expression `DW_OP_bregx R, B`
3774     The `DW_CFA_def_cfa_sf` instruction takes two operands: an unsigned LEB128
3776     displacement B. The required action is to define the current CFA rule to be
3777     equivalent to the result of evaluating the DWARF operation expression
3780     <i>The action is the same as `DW_CFA_def_cfa`, except that the second
3785     The `DW_CFA_def_cfa_register` instruction takes a single unsigned LEB128
3786     operand representing a register number R. The required action is to define
3787     the current CFA rule to be equivalent to the result of evaluating the DWARF
3788     operation expression `DW_OP_bregx R, B` as a location description. B is the
3791     If the subprogram has no current CFA rule, or the rule was defined by a
3792     `DW_CFA_def_cfa_expression` instruction, then the DWARF is ill-formed.
3796     The `DW_CFA_def_cfa_offset` instruction takes a single unsigned LEB128
3797     operand representing a (non-factored) byte displacement B. The required
3798     action is to define the current CFA rule to be equivalent to the result of
3799     evaluating the DWARF operation expression `DW_OP_bregx R, B` as a location
3800     description. R is the old CFA register number.
3802     If the subprogram has no current CFA rule, or the rule was defined by a
3803     `DW_CFA_def_cfa_expression` instruction, then the DWARF is ill-formed.
3807     The `DW_CFA_def_cfa_offset_sf` instruction takes a signed LEB128 operand
3808     representing a factored byte displacement B. The required action is to
3809     define the current CFA rule to be equivalent to the result of evaluating the
3811     location description. R is the old CFA register number.
3813     If the subprogram has no current CFA rule, or the rule was defined by a
3814     `DW_CFA_def_cfa_expression` instruction, then the DWARF is ill-formed.
3816     <i>The action is the same as `DW_CFA_def_cfa_offset`, except that the
3821     The `DW_CFA_def_cfa_expression` instruction takes a single operand encoded
3823     The required action is to define the current CFA rule to be equivalent to
3824     the result of evaluating E with the current context, except the result kind
3825     is a location description, the compilation unit is unspecified, the object
3829     restrictions on the DWARF expression operations that can be used in E.</i>
3831     The DWARF is ill-formed if the result of evaluating E is not a memory byte
3838     The `DW_CFA_undefined` instruction takes a single unsigned LEB128 operand
3839     that represents a register number R. The required action is to set the rule
3840     for the register specified by R to `undefined`.
3844     The `DW_CFA_same_value` instruction takes a single unsigned LEB128 operand
3845     that represents a register number R. The required action is to set the rule
3846     for the register specified by R to `same value`.
3850     The `DW_CFA_offset` instruction takes two operands: a register number R
3851     (encoded with the opcode) and an unsigned LEB128 constant representing a
3852     factored displacement B. The required action is to change the rule for the
3856     > NOTE: Seems this should be named `DW_CFA_offset_uf` since the offset is
3861     The `DW_CFA_offset_extended` instruction takes two unsigned LEB128 operands
3863     instruction is identical to `DW_CFA_offset`, except for the encoding and
3864     size of the register operand.
3866     > NOTE: Seems this should be named `DW_CFA_offset_extended_uf` since the
3871     The `DW_CFA_offset_extended_sf` instruction takes two operands: an unsigned
3878     The `DW_CFA_val_offset` instruction takes two unsigned LEB128 operands
3879     representing a register number R and a factored displacement B. The required
3880     action is to change the rule for the register indicated by R to be a
3883     > NOTE: Seems this should be named `DW_CFA_val_offset_uf` since the
3888     The `DW_CFA_val_offset_sf` instruction takes two operands: an unsigned
3895     The `DW_CFA_register` instruction takes two unsigned LEB128 operands
3896     representing register numbers R1 and R2 respectively. The required action is
3897     to set the rule for the register specified by R1 to be a <i>register(R2)</i>
3902     The `DW_CFA_expression` instruction takes two operands: an unsigned LEB128
3904     representing a DWARF operation expression E. The required action is to
3905     change the rule for the register specified by R to be an
3908     <i>That is, E computes the location description where the register value can
3912     restrictions on the DWARF expression operations that can be used in E.</i>
3916     The `DW_CFA_val_expression` instruction takes two operands: an unsigned
3918     representing a DWARF operation expression E. The required action is to
3919     change the rule for the register specified by R to be a
3922     <i>That is, E computes the value of register R.</i>
3925     restrictions on the DWARF expression operations that can be used in E.</i>
3927     If the result of evaluating E is not a value with a base type size that
3928     matches the register size, then the DWARF is ill-formed.
3932     The `DW_CFA_restore` instruction takes a single operand (encoded with the
3933     opcode) that represents a register number R. The required action is to
3934     change the rule for the register specified by R to the rule assigned it by
3935     the `initial_instructions` in the CIE.
3939     The `DW_CFA_restore_extended` instruction takes a single unsigned LEB128
3941     to `DW_CFA_restore`, except for the encoding and size of the register
3946 > NOTE: These instructions are the same as in DWARF Version 5 section 6.4.2.4.
3950 > NOTE: These instructions are the same as in DWARF Version 5 section 6.4.2.5.
3954 > NOTE: The same as in DWARF Version 5 section 6.4.3.
3958 > NOTE: The same as in DWARF Version 5 section 6.4.4.
3963 > attributes. These would be incorporated into the corresponding DWARF Version 5
3978 > NOTE: The same as in DWARF Version 5 section 7.5.5.
3982 > NOTE: Rename DWARF Version 5 section 7.7 to reflect the unification of
3988 > the unification of location descriptions into DWARF expressions.
3997 The following references provide additional information on the extension.
3999 A reference to the DWARF standard is provided.
4001 A formatted version of this extension is available on the LLVM site. It includes
4002 many figures that help illustrate the textual description, especially of the
4005 Slides and a video of a presentation at the Linux Plumbers Conference 2021
4008 The LLVM compiler extension includes the operations mentioned in the motivating
4013 - [Allow Location Descriptions on the DWARF Expression Stack](https://llvm.org/docs/AMDGPUDwarfExte…