1# Allow Location Descriptions on the DWARF Expression Stack <!-- omit in toc --> 2 3```{contents} 4--- 5local: 6--- 7``` 8 9# 1. Extension 10 11In DWARF 5, expressions are evaluated using a typed value stack, a separate 12location area, and an independent loclist mechanism. This extension unifies all 13three mechanisms into a single generalized DWARF expression evaluation model 14that allows both typed values and location descriptions to be manipulated on the 15evaluation stack. Both single and multiple location descriptions are supported 16on the stack. In addition, the call frame information (CFI) is extended to 17support the full generality of location descriptions. This is done in a manner 18that is backwards compatible with DWARF 5. The extension involves changes to the 19DWARF 5 sections 2.5 (pp 26-38), 2.6 (pp 38-45), and 6.4 (pp 171-182). 20 21The extension permits operations to act on location descriptions in an 22incremental, consistent, and composable manner. It allows a small number of 23operations to be defined to address the requirements of heterogeneous devices as 24well as providing benefits to non-heterogeneous devices. It acts as a foundation 25to provide support for other issues that have been raised that would benefit all 26devices. 27 28Other approaches were explored that involved adding specialized operations and 29rules. However, these resulted in the need for more operations that did not 30compose. It also resulted in operations with context sensitive semantics and 31corner cases that had to be defined. The observation was that numerous 32specialized context sensitive operations are harder for both producers and 33consumers than a smaller number of general composable operations that have 34consistent semantics regardless of context. 35 36First, section [2. Heterogeneous Computing Devices](#heterogeneous-computing-devices) 37describes heterogeneous devices and the features they have that are not addressed by DWARF 5. 38Then section [3. DWARF5](#dwarf-5) presents a brief simplified overview of the DWARF 5 expression 39evaluation model that highlights the difficulties for supporting the 40heterogeneous features. Next, section [4. Extension 41Solution](#extension-solution) provides an overview of the proposal, using 42simplified examples to illustrate how it can address the issues of heterogeneous 43devices and also benefit non-heterogeneous devices. Then overall conclusions are 44covered in section [5. Conclusion](#conclusion). 45Appendix [A. Changes to DWARF Debugging Information Format Version 5](#changes-to-dwarf-debugging-information-format-version-5) gives changes 46relative to the DWARF Version 5 standard. Finally, appendix 47[B. Further Information](#further-information) has references to further information. 48 49# 2. Heterogeneous Computing Devices 50 51GPUs and other heterogeneous computing devices have features not common to CPU 52computing devices. 53 54These devices often have many more registers than a CPU. This helps reduce 55memory accesses which tend to be more expensive than on a CPU due to the much 56larger number of threads concurrently executing. In addition to traditional 57scalar registers of a CPU, these devices often have many wide vector registers. 58 59 60 61They may support masked vector instructions that are used by the compiler to map 62high level language threads onto the lanes of the vector registers. As a 63consequence, multiple language threads execute in lockstep as the vector 64instructions are executed. This is termed single instruction multiple thread 65(SIMT) execution. 66 67 68 69GPUs can have multiple memory address spaces in addition to the single global 70memory address space of a CPU. These additional address spaces are accessed 71using distinct instructions and are often local to a particular thread or group 72of threads. 73 74For example, a GPU may have a per thread block address space that is implemented 75as scratch pad memory with explicit hardware support to isolate portions to 76specific groups of threads created as a single thread block. 77 78A GPU may also use global memory in a non linear manner. For example, to support 79providing a SIMT per lane address space efficiently, there may be instructions 80that support interleaved access. 81 82Through optimization, the source variables may be located across these different 83storage kinds. SIMT execution requires locations to be able to express selection 84of runtime defined pieces of vector registers. With the more complex locations, 85there is a benefit to be able to factorize their calculation which requires all 86location kinds to be supported uniformly, otherwise duplication is necessary. 87 88# 3. DWARF 5 89 90Before presenting the proposed solution to supporting heterogeneous devices, a 91brief overview of the DWARF 5 expression evaluation model will be given to 92highlight the aspects being addressed by the extension. 93 94## 3.1 How DWARF Maps Source Language To Hardware 95 96DWARF is a standardized way to specify debug information. It describes source 97language entities such as compilation units, functions, types, variables, etc. 98It is either embedded directly in sections of the code object executables, or 99split into separate files that they reference. 100 101DWARF maps between source program language entities and their hardware 102representations. For example: 103 104- It maps a hardware instruction program counter to a source language program 105 line, and vice versa. 106- It maps a source language function to the hardware instruction program counter 107 for its entry point. 108- It maps a source language variable to its hardware location when at a 109 particular program counter. 110- It provides information to allow virtual unwinding of hardware registers for a 111 source language function call stack. 112- In addition, it provides numerous other information about the source language 113 program. 114 115In particular, there is great diversity in the way a source language entity 116could be mapped to a hardware location. The location may involve runtime values. 117For example, a source language variable location could be: 118 119- In register. 120- At a memory address. 121- At an offset from the current stack pointer. 122- Optimized away, but with a known compiler time value. 123- Optimized away, but with an unknown value, such as happens for unused 124 variables. 125- Spread across combination of the above kinds of locations. 126- At a memory address, but also transiently loaded into registers. 127 128To support this DWARF 5 defines a rich expression language comprised of loclist 129expressions and operation expressions. Loclist expressions allow the result to 130vary depending on the PC. Operation expressions are made up of a list of 131operations that are evaluated on a simple stack machine. 132 133A DWARF expression can be used as the value of different attributes of different 134debug information entries (DIE). A DWARF expression can also be used as an 135argument to call frame information information (CFI) entry operations. An 136expression is evaluated in a context dictated by where it is used. The context 137may include: 138 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 143 DW_OP_push_object_address operation. 144 145## 3.2 Examples 146 147The following examples illustrate how DWARF expressions involving operations are 148evaluated in DWARF 5. DWARF also has expressions involving location lists that 149are not covered in these examples. 150 151### 3.2.1 Dynamic Array Size 152 153The first example is for an operation expression associated with a DIE attribute 154that provides the number of elements in a dynamic array type. Such an attribute 155dictates that the expression must be evaluated in the context of providing a 156value result kind. 157 158 159 160In this hypothetical example, the compiler has allocated an array descriptor in 161memory and placed the descriptor's address in architecture register SGPR0. The 162first location of the array descriptor is the runtime size of the array. 163 164A possible expression to retrieve the dynamic size of the array is: 165 166 DW_OP_regval_type SGPR0 Generic 167 DW_OP_deref 168 169The expression is evaluated one operation at a time. Operations have operands 170and can pop and push entries on a stack. 171 172 173 174The expression evaluation starts with the first DW_OP_regval_type operation. 175This operation reads the current value of an architecture register specified by 176its first operand: SGPR0. The second operand specifies the size of the data to 177read. The read value is pushed on the stack. Each stack element is a value and 178its associated type. 179 180 181 182The type must be a DWARF base type. It specifies the encoding, byte ordering, 183and size of values of the type. DWARF defines that each architecture has a 184default generic type: it is an architecture specific integral encoding and byte 185ordering, that is the size of the architecture's global memory address. 186 187The DW_OP_deref operation pops a value off the stack, treats it as a global 188memory address, and reads the contents of that location using the generic type. 189It pushes the read value on the stack as the value and its associated generic 190type. 191 192 193 194The evaluation stops when it reaches the end of the expression. The result of an 195expression that is evaluated with a value result kind context is the top element 196of the stack, which provides the value and its type. 197 198### 3.2.2 Variable Location in Register 199 200This example is for an operation expression associated with a DIE attribute that 201provides the location of a source language variable. Such an attribute dictates 202that the expression must be evaluated in the context of providing a location 203result kind. 204 205DWARF defines the locations of objects in terms of location descriptions. 206 207In this example, the compiler has allocated a source language variable in 208architecture register SGPR0. 209 210 211 212A possible expression to specify the location of the variable is: 213 214 DW_OP_regx SGPR0 215 216 217 218The DW_OP_regx operation creates a location description that specifies the 219location of the architecture register specified by the operand: SGPR0. Unlike 220values, location descriptions are not pushed on the stack. Instead they are 221conceptually placed in a location area. Unlike values, location descriptions do 222not have an associated type, they only denote the location of the base of the 223object. 224 225 226 227Again, evaluation stops when it reaches the end of the expression. The result of 228an expression that is evaluated with a location result kind context is the 229location description in the location area. 230 231### 3.2.3 Variable Location in Memory 232 233The next example is for an operation expression associated with a DIE attribute 234that provides the location of a source language variable that is allocated in a 235stack frame. The compiler has placed the stack frame pointer in architecture 236register SGPR0, and allocated the variable at offset 0x10 from the stack frame 237base. The stack frames are allocated in global memory, so SGPR0 contains a 238global memory address. 239 240 241 242A possible expression to specify the location of the variable is: 243 244 DW_OP_regval_type SGPR0 Generic 245 DW_OP_plus_uconst 0x10 246 247 248 249As in the previous example, the DW_OP_regval_type operation pushes the stack 250frame pointer global memory address onto the stack. The generic type is the size 251of a global memory address. 252 253 254 255The DW_OP_plus_uconst operation pops a value from the stack, which must have a 256type with an integral encoding, adds the value of its operand, and pushes the 257result back on the stack with the same associated type. In this example, that 258computes the global memory address of the source language variable. 259 260 261 262Evaluation stops when it reaches the end of the expression. If the expression 263that is evaluated has a location result kind context, and the location area is 264empty, then the top stack element must be a value with the generic type. The 265value is implicitly popped from the stack, and treated as a global memory 266address to create a global memory location description, which is placed in the 267location area. The result of the expression is the location description in the 268location area. 269 270 271 272### 3.2.4 Variable Spread Across Different Locations 273 274This example is for a source variable that is partly in a register, partly undefined, and partly in memory. 275 276 277 278DWARF defines composite location descriptions that can have one or more parts. 279Each part specifies a location description and the number of bytes used from it. 280The following operation expression creates a composite location description. 281 282 DW_OP_regx SGPR3 283 DW_OP_piece 4 284 DW_OP_piece 2 285 DW_OP_bregx SGPR0 0x10 286 DW_OP_piece 2 287 288 289 290The DW_OP_regx operation creates a register location description in the location 291area. 292 293 294 295The first DW_OP_piece operation creates an incomplete composite location 296description in the location area with a single part. The location description in 297the location area is used to define the beginning of the part for the size 298specified by the operand, namely 4 bytes. 299 300 301 302A subsequent DW_OP_piece adds a new part to an incomplete composite location 303description already in the location area. The parts form a contiguous set of 304bytes. If there are no other location descriptions in the location area, and no 305value on the stack, then the part implicitly uses the undefined location 306description. Again, the operand specifies the size of the part in bytes. The 307undefined location description can be used to indicate a part that has been 308optimized away. In this case, 2 bytes of undefined value. 309 310 311 312The DW_OP_bregx operation reads the architecture register specified by the first 313operand (SGPR0) as the generic type, adds the value of the second operand 314(0x10), and pushes the value on the stack. 315 316 317 318The next DW_OP_piece operation adds another part to the already created 319incomplete composite location. 320 321If there is no other location in the location area, but there is a value on 322stack, the new part is a memory location description. The memory address used is 323popped from the stack. In this case, the operand of 2 indicates there are 2 324bytes from memory. 325 326 327 328Evaluation stops when it reaches the end of the expression. If the expression 329that is evaluated has a location result kind context, and the location area has 330an incomplete composite location description, the incomplete composite location 331is implicitly converted to a complete composite location description. The result 332of the expression is the location description in the location area. 333 334 335 336### 3.2.5 Offsetting a Composite Location 337 338This example attempts to extend the previous example to offset the composite 339location description it created. The [3.2.3 Variable Location in 340Memory](#variable-location-in-memory) example conveniently used the DW_OP_plus 341operation to offset a memory address. 342 343 DW_OP_regx SGPR3 344 DW_OP_piece 4 345 DW_OP_piece 2 346 DW_OP_bregx SGPR0 0x10 347 DW_OP_piece 2 348 DW_OP_plus_uconst 5 349 350 351 352However, DW_OP_plus cannot be used to offset a composite location. It only 353operates on the stack. 354 355 356 357To offset a composite location description, the compiler would need to make a 358different composite location description, starting at the part corresponding to 359the offset. For example: 360 361 DW_OP_piece 1 362 DW_OP_bregx SGPR0 0x10 363 DW_OP_piece 2 364 365This illustrates that operations on stack values are not composable with 366operations on location descriptions. 367 368### 3.2.6 Pointer to Member 369 370> NOTE: Without loss of generality, DWARF 4 is used in this example as full 371> support for DWARF 5 is not present in the versions of the tools used. No 372> feature of DWARF 5 provides a remedy for this issue. 373 374This example highlights the inability of DWARF 5 to describe C++ 375pointer-to-member use semantics. 376 377The mechanism DWARF 5 provides for describing pointer-to-member use is 378`DW_AT_use_location`, which is defined as encoding a location description which 379computes the address of the member pointed to by a pointer-to-member, given the 380pointer-to-member object and the address of the containing object. 381 382That is, when a debug agent wishes to evaluate a pointer-to-member access 383operation, it first pushes two values onto the DWARF expression stack: 384 385* The pointer-to-member object 386* The address of the containing object 387 388It then evaluates the location description associated with the 389`DW_AT_use_location` of the pointer-to-member type, and interprets the result 390as the address of the member pointed to by the pointer-to-member. 391 392Consider the following C++ source file `s.cc`: 393 394```cpp 395struct s { 396 int m; 397 int n; 398}; 399int s::* p; 400``` 401 402When compiled with GCC and inspected with dwarfdump: 403 404``` 405$ g++ -gdwarf-5 -O3 -c s.cc 406$ dwarfdump s.o 407< 1><0x0000001e> DW_TAG_structure_type 408 DW_AT_name s 409 DW_AT_byte_size 0x00000008 410 DW_AT_sibling <0x0000003c> 411< 2><0x00000029> DW_TAG_member 412 DW_AT_name m 413 DW_AT_type <0x0000003c> 414 DW_AT_data_member_location 0 415< 2><0x00000032> DW_TAG_member 416 DW_AT_name n 417 DW_AT_type <0x0000003c> 418 DW_AT_data_member_location 4 419< 1><0x0000003c> DW_TAG_base_type 420 DW_AT_byte_size 0x00000004 421 DW_AT_encoding DW_ATE_signed 422 DW_AT_name int 423< 1><0x00000043> DW_TAG_ptr_to_member_type 424 DW_AT_containing_type <0x0000001e> 425 DW_AT_type <0x0000003c> 426 DW_AT_use_location len 0x0001: 22: DW_OP_plus 427< 1><0x0000004e> DW_TAG_variable 428 DW_AT_name p 429 DW_AT_type <0x00000043> 430 DW_AT_external yes(1) 431 DW_AT_location len 0x0009: 030000000000000000: DW_OP_addr 0x00000000 432``` 433 434Note the location description for `DW_AT_use_location` is `DW_OP_plus`, which 435reflects the GCC implementation of the pointer-to-member as an integral byte 436offset within the containing object. For example, the value of `&s::m` in this 437implementation is `offsetof(s, m)` and the value of `&s::n` is `offsetof(s, n)`: 438 439```cpp 440struct s { 441 int m; // offsetof(s, m) == 0 442 int n; // offsetof(s, n) == 4 443} o; // &o == 0xff00 444int s::* p; 445int *i; 446 447p = &s::m; // p == 0 448i = &(o.*p); // i == 0xff00 + 0 449p = &s::n; // p == 4 450i = &(o.*p); // i == 0xff00 + 4 451``` 452 453The expression `DW_OP_plus` accurately describes this implementation so long as 454the entire containing object resides in memory in the default address space. 455 456However, what if the containing object or the member pointed to are not at any 457default address space address? 458 459The compiler may store the containing object in memory in any address space, 460in a register, recompute its value at each use, or compose any of these in 461arbitrary ways. 462 463The richness of the existing DWARF 5 expression language is a reflection of the 464diversity of possible implementation strategies and optimization choices 465affecting the location of an object in a program, and (modulo address spaces) 466it can describe all of these locations for variables. However, the moment we 467look at a pointer-to-member use we are restricted to only objects residing in a 468contiguous piece of memory in the default address space. 469 470To demonstrate the problem, consider a program which GCC chooses to optimize in 471such a way that the containing object is not in memory at all: 472 473ptm.h: 474```cpp 475struct s { 476 int m; 477 int n; 478}; 479void i(int); 480extern int t; 481void f(s x, int s::* p); 482``` 483 484ptm.cc: 485```cpp 486#include "ptm.h" 487void f(s x, int s::* p) { 488 for (int a = 0; a < t; ++a) { 489 x.m += a + x.n; 490 i(x.*p); 491 } 492} 493``` 494 495main.cc: 496```cpp 497#include "ptm.h" 498int t = 100; 499void i(int) {} 500int main(int argc, char *argv[]) { 501 s x = { 0, 1 }; 502 f(x, &s::m); 503} 504``` 505 506When compiled and run under GDB: 507 508``` 509$ g++-9 -gdwarf-4 -O3 -c main.cc -o main.o 510$ g++-9 -gdwarf-4 -O3 -c ptm.cc -o ptm.o 511$ g++-9 main.o ptm.o -o use_location.out 512$ gdb ./use_location.out 513(gdb) maint set dwarf always-disassemble 514(gdb) b ptm.cc:5 515Breakpoint 1 at 0x119e: file ptm.cc, line 5. 516(gdb) r 517 518Breakpoint 1, f (x=..., p=<optimized out>) at ptm.cc:5 5195 i(x.*p); 520``` 521 522Note that the compiler has promoted the entire object `x` into register `rdi` 523for the body of the loop: 524 525``` 526(gdb) info addr x 527Symbol "x" is multi-location: 528 Range 0x555555555160-0x5555555551af: a complex DWARF expression: 529 0: DW_OP_reg5 [$rdi] 530 531 Range 0x5555555551af-0x5555555551ba: a complex DWARF expression: 532 0: DW_OP_fbreg -56 533 534. 535(gdb) p $pc 536$1 = (void (*)(void)) 0x55555555519e <f(s, int s::*)+62> 537``` 538 539And so it is impossible to interpret `DW_OP_use_location` in this case: 540 541``` 542(gdb) p x.*p 543Address requested for identifier "x" which is in register $rdi 544``` 545 546With location descriptions on the stack, the definition of `DW_OP_use_location` 547can be modified by replacing every instance of "address" with "location 548description", as is described in [Type Entries](#type-entries). 549 550To implement the fully generalized version of this attribute, GCC would only 551need to change the expression from `DW_OP_plus` to `DW_OP_swap, 552DW_OP_LLVM_offset`. 553 554### 3.2.7 Virtual Base Class 555 556> NOTE: Without loss of generality, DWARF 4 is used in this example as full 557> support for DWARF 5 is not present in the versions of the tools used. No 558> feature of DWARF 5 provides a remedy for this issue. 559 560This example highlights the inability of DWARF 5 to describe C++ 561virtual inheritance semantics. 562 563The mechanism DWARF 5 provides for describing the location of an inherited 564subobject is `DW_AT_data_member_location`. This attribute is overloaded to 565describe both data member locations and inherited subobject locations, and 566in each case has multiple possible forms: 567 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. 572 573Only the attribute describing a subobject, and only the location description 574form are considered here. 575 576In this case, when a debug agent wishes to locate the subobject, it first 577pushes the address of the derived object onto the DWARF expression stack. It 578then evaluates the location description associated with the 579`DW_AT_data_member_location` of the `DW_TAG_inheritence` DIE corresponding to 580the inherited subobject. 581 582Consider the following C++ source file `ab.cc`: 583 584```cpp 585class A { 586public: 587 char x; 588}; 589class B 590: public virtual A {} o; 591``` 592 593When compiled with GCC and inspected with dwarfdump: 594 595``` 596$ g++ -gdwarf-5 -O3 -c ab.cc 597$ dwarfdump ab.o 598< 1><0x0000002a> DW_TAG_class_type 599 DW_AT_name A 600 DW_AT_byte_size 0x00000001 601 DW_AT_sibling <0x00000042> 602< 1><0x00000049> DW_TAG_class_type 603 DW_AT_name B 604 DW_AT_byte_size 0x00000010 605 DW_AT_containing_type <0x00000049> 606 DW_AT_sibling <0x000000f9> 607< 2><0x00000058> DW_TAG_inheritance 608 DW_AT_type <0x0000002a> 609 DW_AT_data_member_location len 0x0006: 1206481c0622: 610 DW_OP_dup DW_OP_deref DW_OP_lit24 DW_OP_minus DW_OP_deref DW_OP_plus 611 DW_AT_virtuality DW_VIRTUALITY_virtual 612 DW_AT_accessibility DW_ACCESS_public 613``` 614 615This `DW_AT_data_member_location` expression describes the dynamic process of 616locating the `A`-in-`B` subobject according to the [Itanium 617ABI](https://refspecs.linuxfoundation.org/cxxabi-1.86.html#layout). A diagram 618of the logical layout of class `B` is: 619 620``` 6210: class B 6220: vptr B 6238: class A 6248: A::x 625``` 626 627That is, the address of an object of class `B` is equivalent to the address for 628the `vtable` pointer for `B`. As there are no other direct data members of `B` 629the primary base class subobject of class `A` comes next, and there is no 630intervening padding as the subobject alignment requirements are already 631satisfied. 632 633The `vtable` pointer for `B` contains an entry `vbase_offset` for each virtual 634base class. In this case, that table layout is: 635 636``` 637-24: vbase_offset[A]=8 638-16: offset_to_top=0 639 -8: B RTTI 640 0: <vtable for B> 641``` 642 643That 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`. 645 646Thus, in order to implement `DW_AT_data_member_location` for `A`-in-`B`, the 647expression needs to index to a statically known byte offset of `-24` through 648`vptr B` to lookup `vbase_offset` for `A`-in-`B`. It must then offset the 649location of `B` by the dynamic value of `vbase_offset` (in this case `8`) to 650arrive at the location of the inherited subobject. 651 652This definition shares the same problem as example [3.2.6](#pointer-to-member) 653in that it relies on the address of the derived object and inherited subobject, 654when there is no guarantee either or both have any address at all. 655 656To demonstrate the problem, consider a program which GCC chooses to optimize in 657such a way that the derived object is not in memory at all: 658 659f.h: 660```cpp 661class A { 662public: 663 char x; 664}; 665class B 666: public virtual A {}; 667void f(B b); 668``` 669 670f.cc: 671```cpp 672#include "f.h" 673void f(B b) {} 674``` 675 676main.cc: 677```cpp 678#include "f.h" 679int main(int argc, char *argv[]) { 680 B b; 681 b.x = 42; 682 f(b); 683 return b.x; 684} 685``` 686 687When compiled and run under GDB: 688 689``` 690$ g++-9 -gdwarf-4 -O3 -c main.cc -o main.o 691$ g++-9 -gdwarf-4 -O3 -c f.cc -o f.o 692$ g++-9 main.o f.o -o cpp-vbase.out 693(gdb) maint set dwarf always-disassemble 694(gdb) b main.cc:6 695Breakpoint 1 at 0x1090: file main.cc, line 6. 696(gdb) r 697 698Breakpoint 1, main (argc=<optimized out>, argv=<optimized out>) at main.cc:6 6996 return b.x; 700``` 701 702Note that the compiler has elided storage for the entire object `x` in the 703body of `main()`: 704 705``` 706(gdb) info addr b 707Symbol "b" is multi-location: 708 Range 0x555555555078-0x5555555550af: a complex DWARF expression: 709 0: DW_OP_piece 8 (bytes) 710 2: DW_OP_const1u 42 711 4: DW_OP_stack_value 712 5: DW_OP_piece 1 (bytes) 713 7: DW_OP_piece 7 (bytes) 714 715. 716(gdb) p $pc 717$1 = (void (*)(void)) 0x555555555090 <main(int, char**)+48> 718``` 719 720And so it is impossible to interpret `DW_OP_data_member_location` in this case: 721 722``` 723(gdb) p b 724$2 = {<A> = <invalid address>, _vptr.B = <optimized out>} 725``` 726 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 730> issue in DWARF 5 described here. 731 732With location descriptions on the stack, the definition of 733`DW_OP_data_member_location` can be modified by replacing every instance of 734"address" with "location description", as is described in [A.5 Type Entries](#type-entries). 735 736To implement the fully generalized version of this attribute, GCC would only 737need to change the last operation in the expression from `DW_OP_plus` to 738`DW_OP_LLVM_offset`. 739 740## 3.3 Limitations 741 742DWARF 5 is unable to describe variables in runtime indexed parts of registers. 743This is required to describe a source variable that is located in a lane of a 744SIMT vector register. 745 746Some features only work when located in global memory. The type attribute 747expressions require a base object which could be in any kind of location. 748 749DWARF procedures can only accept global memory address arguments. This limits 750the ability to factorize the creation of locations that involve other location 751kinds. 752 753There are no vector base types. This is required to describe vector registers. 754 755There is no operation to create a memory location in a non-global address space. 756Only the dereference operation supports providing an address space. 757 758CFI location expressions do not allow composite locations or non-global address 759space memory locations. Both these are needed in optimized code for devices with 760vector registers and address spaces. 761 762Bit field offsets are only supported in a limited way for register locations. 763Supporting them in a uniform manner for all location kinds is required to 764support languages with bit sized entities. 765 766# 4. Extension Solution 767 768This section outlines the extension to generalize the DWARF expression evaluation 769model to allow location descriptions to be manipulated on the stack. It presents 770a number of simplified examples to demonstrate the benefits and how the extension 771solves the issues of heterogeneous devices. It presents how this is done in 772a manner that is backwards compatible with DWARF 5. 773 774## 4.1 Location Description 775 776In order to have consistent, composable operations that act on location 777descriptions, the extension defines a uniform way to handle all location kinds. 778That includes memory, register, implicit, implicit pointer, undefined, and 779composite location descriptions. 780 781Each kind of location description is conceptually a zero-based offset within a 782piece of storage. The storage is a contiguous linear organization of a certain 783number of bytes (see below for how this is extended to support bit sized 784storage). 785 786- For global memory, the storage is the linear stream of bytes of the 787 architecture's address size. 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, 792 and byte ordering. 793- For undefined, it is an infinitely sized linear stream where every byte is 794 undefined. 795- For composite, it is a linear stream of bytes defined by the composite's parts. 796 797## 4.2 Stack Location Description Operations 798 799The DWARF expression stack is extended to allow each stack entry to either be a 800value or a location description. 801 802Evaluation rules are defined to implicitly convert a stack element that is a 803value to a location description, or vice versa, so that all DWARF 5 expressions 804continue to have the same semantics. This reflects that a memory address is 805effectively used as a proxy for a memory location description. 806 807For each place that allows a DWARF expression to be specified, it is defined if 808the expression is to be evaluated as a value or a location description. 809 810Existing DWARF expression operations that are used to act on memory addresses 811are generalized to act on any location description kind. For example, the 812DW_OP_deref operation pops a location description rather than a memory address 813value from the stack and reads the storage associated with the location kind 814starting at the location description's offset. 815 816Existing DWARF expression operations that create location descriptions are 817changed to pop and push location descriptions on the stack. For example, the 818DW_OP_value, DW_OP_regx, DW_OP_implicit_value, DW_OP_implicit_pointer, 819DW_OP_stack_value, and DW_OP_piece. 820 821New operations that act on location descriptions can be added. For example, a 822DW_OP_offset operation that modifies the offset of the location description on 823top of the stack. Unlike the DW_OP_plus operation that only works with memory 824address, a DW_OP_offset operation can work with any location kind. 825 826To allow incremental and nested creation of composite location descriptions, a 827DW_OP_piece_end can be defined to explicitly indicate the last part of a 828composite. Currently, creating a composite must always be the last operation of 829an expression. 830 831A DW_OP_undefined operation can be defined that explicitly creates the undefined 832location description. Currently this is only possible as a piece of a composite 833when the stack is empty. 834 835## 4.3 Examples 836 837This section provides some motivating examples to illustrate the benefits that 838result from allowing location descriptions on the stack. 839 840### 4.3.1 Source Language Variable Spilled to Part of a Vector Register 841 842A compiler generating code for a GPU may allocate a source language variable 843that it proves has the same value for every lane of a SIMT thread in a scalar 844register. It may then need to spill that scalar register. To avoid the high cost 845of spilling to memory, it may spill to a fixed lane of one of the numerous 846vector registers. 847 848 849 850The following expression defines the location of a source language variable that 851the compiler allocated in a scalar register, but had to spill to lane 5 of a 852vector register at this point of the code. 853 854 DW_OP_regx VGPR0 855 DW_OP_offset_uconst 20 856 857 858 859The DW_OP_regx pushes a register location description on the stack. The storage 860for the register is the size of the vector register. The register location 861description conceptually references that storage with an initial offset of 0. 862The architecture defines the byte ordering of the register. 863 864 865 866The DW_OP_offset_uconst pops a location description off the stack, adds its 867operand value to the offset, and pushes the updated location description back on 868the stack. In this case the source language variable is being spilled to lane 5 869and each lane's component which is 32-bits (4 bytes), so the offset is 5*4=20. 870 871 872 873The result of the expression evaluation is the location description on the top 874of the stack. 875 876An alternative approach could be for the target to define distinct register 877names for each part of each vector register. However, this is not practical for 878GPUs due to the sheer number of registers that would have to be defined. It 879would also not permit a runtime index into part of the whole register to be used 880as shown in the next example. 881 882### 4.3.2 Source Language Variable Spread Across Multiple Vector Registers 883 884A compiler may generate SIMT code for a GPU. Each source language thread of 885execution is mapped to a single lane of the GPU thread. Source language 886variables that are mapped to a register, are mapped to the lane component of the 887vector registers corresponding to the source language's thread of execution. 888 889The location expression for such variables must therefore be executed in the 890context of the focused source language thread of execution. A DW_OP_push_lane 891operation can be defined to push the value of the lane for the currently focused 892source language thread of execution. The value to use would be provided by the 893consumer of DWARF when it evaluates the location expression. 894 895If the source language variable is larger than the size of the vector register 896lane component, then multiple vector registers are used. Each source language 897thread of execution will only use the vector register components for its 898associated lane. 899 900 901 902The following expression defines the location of a source language variable that 903has to occupy two vector registers. A composite location description is created 904that combines the two parts. It will give the correct result regardless of which 905lane corresponds to the source language thread of execution that the user is 906focused on. 907 908 DW_OP_regx VGPR0 909 DW_OP_push_lane 910 DW_OP_uconst 4 911 DW_OP_mul 912 DW_OP_offset 913 DW_OP_piece 4 914 DW_OP_regx VGPR1 915 DW_OP_push_lane 916 DW_OP_uconst 4 917 DW_OP_mul 918 DW_OP_offset 919 DW_OP_piece 4 920 921 922 923The DW_OP_regx VGPR0 pushes a location description for the first register. 924 925 926 927The DW_OP_push_lane; DW_OP_uconst 4; DW_OP_mul calculates the offset for the 928focused lanes vector register component as 4 times the lane number. 929 930 931 932 933 934 935 936The DW_OP_offset adjusts the register location description's offset to the 937runtime computed value. 938 939 940 941The DW_OP_piece either creates a new composite location description, or adds a 942new part to an existing incomplete one. It pops the location description to use 943for the new part. It then pops the next stack element if it is an incomplete 944composite location description, otherwise it creates a new incomplete composite 945location description with no parts. Finally it pushes the incomplete composite 946after adding the new part. 947 948In this case a register location description is added to a new incomplete 949composite location description. The 4 of the DW_OP_piece specifies the size of 950the register storage that comprises the part. Note that the 4 bytes start at the 951computed register offset. 952 953For backwards compatibility, if the stack is empty or the top stack element is 954an incomplete composite, an undefined location description is used for the part. 955If the top stack element is a generic base type value, then it is implicitly 956converted to a global memory location description with an offset equal to the 957value. 958 959 960 961The rest of the expression does the same for VGPR1. However, when the 962DW_OP_piece is evaluated there is an incomplete composite on the stack. So the 963VGPR1 register location description is added as a second part. 964 965 966 967 968 969 970 971 972 973 974 975 976 977At the end of the expression, if the top stack element is an incomplete 978composite location description, it is converted to a complete location 979description and returned as the result. 980 981 982 983### 4.3.3 Source Language Variable Spread Across Multiple Kinds of Locations 984 985This example is the same as the previous one, except the first 2 bytes of the 986second vector register have been spilled to memory, and the last 2 bytes have 987been proven to be a constant and optimized away. 988 989 990 991 DW_OP_regx VGPR0 992 DW_OP_push_lane 993 DW_OP_uconst 4 994 DW_OP_mul 995 DW_OP_offset 996 DW_OP_piece 4 997 DW_OP_addr 0xbeef 998 DW_OP_piece 2 999 DW_OP_uconst 0xf00d 1000 DW_OP_stack_value 1001 DW_OP_piece 2 1002 DW_OP_piece_end 1003 1004The first 6 operations are the same. 1005 1006 1007 1008The DW_OP_addr operation pushes a global memory location description on the 1009stack with an offset equal to the address. 1010 1011 1012 1013The next DW_OP_piece adds the global memory location description as the next 2 1014byte part of the composite. 1015 1016 1017 1018The DW_OP_uconst 0xf00d; DW_OP_stack_value pushes an implicit location 1019description on the stack. The storage of the implicit location description is 1020the representation of the value 0xf00d using the generic base type's encoding, 1021size, and byte ordering. 1022 1023 1024 1025 1026 1027The final DW_OP_piece adds 2 bytes of the implicit location description as the 1028third part of the composite location description. 1029 1030 1031 1032The DW_OP_piece_end operation explicitly makes the incomplete composite location 1033description into a complete location description. This allows a complete 1034composite location description to be created on the stack that can be used as 1035the location description of another following operation. For example, the 1036DW_OP_offset can be applied to it. More practically, it permits creation of 1037multiple composite location descriptions on the stack which can be used to pass 1038arguments to a DWARF procedure using a DW_OP_call* operation. This can be 1039beneficial to factor the incrementally creation of location descriptions. 1040 1041 1042 1043### 4.3.4 Address Spaces 1044 1045Heterogeneous devices can have multiple hardware supported address spaces which 1046use specific hardware instructions to access them. 1047 1048For example, GPUs that use SIMT execution may provide hardware support to access 1049memory such that each lane can see a linear memory view, while the backing 1050memory is actually being accessed in an interleaved manner so that the locations 1051for each lanes Nth dword are contiguous. This minimizes cache lines read by the 1052SIMT execution. 1053 1054 1055 1056The following expression defines the location of a source language variable that 1057is allocated at offset 0x10 in the current subprograms stack frame. The 1058subprogram stack frames are per lane and reside in an interleaved address space. 1059 1060 DW_OP_regval_type SGPR0 Generic 1061 DW_OP_uconst 1 1062 DW_OP_form_aspace_address 1063 DW_OP_offset 0x10 1064 1065 1066 1067The DW_OP_regval_type operation pushes the contents of SGPR0 as a generic value. 1068This is the register that holds the address of the current stack frame. 1069 1070 1071 1072The DW_OP_uconst operation pushes the address space number. Each architecture 1073defines the numbers it uses in DWARF. In this case, address space 1 is being 1074used as the per lane memory. 1075 1076 1077 1078The DW_OP_form_aspace_address operation pops a value and an address space 1079number. Each address space is associated with a separate storage. A memory 1080location description is pushed which refers to the address space's storage, with 1081an offset of the popped value. 1082 1083 1084 1085All operations that act on location descriptions work with memory locations 1086regardless of their address space. 1087 1088Every architecture defines address space 0 as the default global memory address 1089space. 1090 1091Generalizing memory location descriptions to include an address space component 1092avoids having to create specialized operations to work with address spaces. 1093 1094The source variable is at offset 0x10 in the stack frame. The DW_OP_offset 1095operation works on memory location descriptions that have an address space just 1096like for any other kind of location description. 1097 1098 1099 1100The only operations in DWARF 5 that take an address space are DW_OP_xderef*. 1101They treat a value as the address in a specified address space, and read its 1102contents. There is no operation to actually create a location description that 1103references an address space. There is no way to include address space memory 1104locations in parts of composite locations. 1105 1106Since DW_OP_piece now takes any kind of location description for its pieces, it 1107is now possible for parts of a composite to involve locations in different 1108address spaces. For example, this can happen when parts of a source variable 1109allocated in a register are spilled to a stack frame that resides in the 1110non-global address space. 1111 1112### 4.3.5 Bit Offsets 1113 1114With the generalization of location descriptions on the stack, it is possible to 1115define a DW_OP_bit_offset operation that adjusts the offset of any kind of 1116location in terms of bits rather than bytes. The offset can be a runtime 1117computed value. This is generally useful for any source language that support 1118bit sized entities, and for registers that are not a whole number of bytes. 1119 1120DWARF 5 only supports bit fields in composites using DW_OP_bit_piece. It does 1121not support runtime computed offsets which can happen for bit field packed 1122arrays. It is also not generally composable as it must be the last part of an 1123expression. 1124 1125The following example defines a location description for a source variable that 1126is allocated starting at bit 20 of a register. A similar expression could be 1127used if the source variable was at a bit offset within memory or a particular 1128address space, or if the offset is a runtime value. 1129 1130 1131 1132 DW_OP_regx SGPR3 1133 DW_OP_uconst 20 1134 DW_OP_bit_offset 1135 1136 1137 1138 1139 1140 1141 1142The DW_OP_bit_offset operation pops a value and location description from the 1143stack. It pushes the location description after updating its offset using the 1144value as a bit count. 1145 1146 1147 1148The ordering of bits within a byte, like byte ordering, is defined by the target 1149architecture. A base type could be extended to specify bit ordering in addition 1150to byte ordering. 1151 1152## 4.4 Call Frame Information (CFI) 1153 1154DWARF defines call frame information (CFI) that can be used to virtually unwind 1155the subprogram call stack. This involves determining the location where register 1156values have been spilled. DWARF 5 limits these locations to either be registers 1157or global memory. As shown in the earlier examples, heterogeneous devices may 1158spill registers to parts of other registers, to non-global memory address 1159spaces, or even a composite of different location kinds. 1160 1161Therefore, the extension extends the CFI rules to support any kind of location 1162description, and operations to create locations in address spaces. 1163 1164## 4.5 Objects Not In Byte Aligned Global Memory 1165 1166DWARF 5 only effectively supports byte aligned memory locations on the stack by 1167using a global memory address as a proxy for a memory location description. This 1168is a problem for attributes that define DWARF expressions that require the 1169location of some source language entity that is not allocated in byte aligned 1170global memory. 1171 1172For example, the DWARF expression of the DW_AT_data_member_location attribute is 1173evaluated with an initial stack containing the location of a type instance 1174object. That object could be located in a register, in a non-global memory 1175address space, be described by a composite location description, or could even 1176be an implicit location description. 1177 1178A similar problem exists for DWARF expressions that use the 1179DW_OP_push_object_address operation. This operation pushes the location of a 1180program object associated with the attribute that defines the expression. 1181 1182Allowing any kind of location description on the stack permits the DW_OP_call* 1183operations to be used to factor the creation of location descriptions. The 1184inputs and outputs of the call are passed on the stack. For example, on GPUs an 1185expression can be defined to describe the effective PC of inactive lanes of SIMT 1186execution. This is naturally done by composing the result of expressions for 1187each nested control flow region. This can be done by making each control flow 1188region have its own DWARF procedure, and then calling it from the expressions of 1189the nested control flow regions. The alternative is to make each control flow 1190region have the complete expression which results in much larger DWARF and is 1191less convenient to generate. 1192 1193GPU compilers work hard to allocate objects in the larger number of registers to 1194reduce memory accesses, they have to use different memory address spaces, and 1195they perform optimizations that result in composites of these. Allowing 1196operations to work with any kind of location description enables creating 1197expressions that support all of these. 1198 1199Full general support for bit fields and implicit locations benefits 1200optimizations on any target. 1201 1202## 4.6 Higher Order Operations 1203 1204The generalization allows an elegant way to add higher order operations that 1205create location descriptions out of other location descriptions in a general 1206composable manner. 1207 1208For example, a DW_OP_extend operation could create a composite location 1209description out of a location description, an element size, and an element 1210count. The resulting composite would effectively be a vector of element count 1211elements with each element being the same location description of the specified 1212bit size. 1213 1214A DW_OP_select_bit_piece operation could create a composite location description 1215out of two location descriptions, a bit mask value, and an element size. The 1216resulting composite would effectively be a vector of elements, selecting from 1217one of the two input locations according to the bit mask. 1218 1219These could be used in the expression of an attribute that computes the 1220effective PC of lanes of SIMT execution. The vector result efficiently computes 1221the PC for each SIMT lane at once. The mask could be the hardware execution mask 1222register that controls which SIMT lanes are executing. For active divergent 1223lanes the vector element would be the current PC, and for inactive divergent 1224lanes the PC would correspond to the source language line at which the lane is 1225logically positioned. 1226 1227Similarly, a DW_OP_overlay_piece operation could be defined that creates a 1228composite location description out of two location descriptions, an offset 1229value, and a size. The resulting composite would consist of parts that are 1230equivalent to one of the location descriptions, but with the other location 1231description replacing a slice defined by the offset and size. This could be used 1232to efficiently express a source language array that has had a set of elements 1233promoted into a vector register when executing a set of iterations of a loop in 1234a SIMD manner. 1235 1236## 4.7 Objects In Multiple Places 1237 1238A compiler may allocate a source variable in stack frame memory, but for some 1239range of code may promote it to a register. If the generated code does not 1240change the register value, then there is no need to save it back to memory. 1241Effectively, during that range, the source variable is in both memory and a 1242register. If a consumer, such as a debugger, allows the user to change the value 1243of the source variable in that PC range, then it would need to change both 1244places. 1245 1246DWARF 5 supports loclists which are able to specify the location of a source 1247language entity is in different places at different PC locations. It can also 1248express that a source language entity is in multiple places at the same time. 1249 1250DWARF 5 defines operation expressions and loclists separately. In general, this 1251is adequate as non-memory location descriptions can only be computed as the last 1252step of an expression evaluation. 1253 1254However, allowing location descriptions on the stack permits non-memory location 1255descriptions to be used in the middle of expression evaluation. For example, the 1256DW_OP_call* and DW_OP_implicit_pointer operations can result in evaluating the 1257expression of a DW_AT_location attribute of a DIE. The DW_AT_location attribute 1258allows the loclist form. So the result could include multiple location 1259descriptions. 1260 1261Similarly, the DWARF expression associated with attributes such as 1262DW_AT_data_member_location that are evaluated with an initial stack containing a 1263location description, or a DWARF operation expression that uses the 1264DW_OP_push_object_address operation, may want to act on the result of another 1265expression that returned a location description involving multiple places. 1266 1267Therefore, the extension needs to define how expression operations that use those 1268results will behave. The extension does this by generalizing the expression stack 1269to allow an entry to be one or more single location descriptions. In doing this, 1270it unifies the definitions of DWARF operation expressions and loclist 1271expressions in a natural way. 1272 1273All operations that act on location descriptions are extended to act on multiple 1274single location descriptions. For example, the DW_OP_offset operation adds the 1275offset to each single location description. The DW_OP_deref* operations simply 1276read the storage of one of the single location descriptions, since multiple 1277single location descriptions must all hold the same value. Similarly, if the 1278evaluation of a DWARF expression results in multiple single location 1279descriptions, the consumer can ensure any updates are done to all of them, and 1280any reads can use any one of them. 1281 1282# 5. Conclusion 1283 1284A strength of DWARF is that it has generally sought to provide generalized 1285composable solutions that address many problems, rather than solutions that only 1286address one-off issues. This extension attempts to follow that tradition by 1287defining a backwards compatible composable generalization that can address a 1288significant family of issues. It addresses the specific issues present for 1289heterogeneous computing devices, provides benefits for non-heterogeneous 1290devices, and can help address a number of other previously reported issues. 1291 1292# A. Changes to DWARF Debugging Information Format Version 5 1293 1294> NOTE: This appendix provides changes relative to DWARF Version 5. It has been 1295> defined such that it is backwards compatible with DWARF Version 5. 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 1298> otherwise. Definitions are given to clarify how existing expression 1299> operations, CFI operations, and attributes behave with respect to generalized 1300> location descriptions that support multiple places. 1301> 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 1304> > may need further consideration. 1305 1306## A.2 General Description 1307 1308### A.2.5 DWARF Expressions 1309 1310> NOTE: This section, and its nested sections, replaces DWARF Version 5 section 1311> 2.5 and section 2.6. It is based on the text of the existing DWARF Version 5 1312> standard. 1313 1314DWARF expressions describe how to compute a value or specify a location. 1315 1316<i>The evaluation of a DWARF expression can provide the location of an object, 1317the value of an array bound, the length of a dynamic string, the desired value 1318itself, and so on.</i> 1319 1320If the evaluation of a DWARF expression does not encounter an error, then it can 1321either result in a value (see [2.5.2 DWARF Expression 1322Value](#dwarf-expression-value)) or a location description (see [2.5.3 DWARF 1323Location Description](#dwarf-location-description)). When a DWARF expression 1324is evaluated, it may be specified whether a value or location description is 1325required as the result kind. 1326 1327If a result kind is specified, and the result of the evaluation does not match 1328the specified result kind, then the implicit conversions described in 1329[2.5.4.4.3 Memory Location Description Operations](#memory-location-description-operations) 1330are performed if valid. Otherwise, the DWARF expression is ill-formed. 1331 1332If the evaluation of a DWARF expression encounters an evaluation error, then the 1333result is an evaluation error. 1334 1335> NOTE: Decided to define the concept of an evaluation error. An alternative is 1336> to introduce an undefined value base type in a similar way to location 1337> descriptions having an undefined location description. Then operations that 1338> encounter an evaluation error can return the undefined location description or 1339> value with an undefined base type. 1340> 1341> All operations that act on values would return an undefined entity if given an 1342> undefined value. The expression would then always evaluate to completion, and 1343> can be tested to determine if it is an undefined entity. 1344> 1345> However, this would add considerable additional complexity and does not match 1346> that GDB throws an exception when these evaluation errors occur. 1347 1348If a DWARF expression is ill-formed, then the result is undefined. 1349 1350The following sections detail the rules for when a DWARF expression is 1351ill-formed or results in an evaluation error. 1352 1353A DWARF expression can either be encoded as an operation expression (see [2.5.4 1354DWARF Operation Expressions](#dwarf-operation-expressions)), or as a 1355location list expression (see [2.5.5 DWARF Location List 1356Expressions](#dwarf-location-list-expressions)). 1357 1358#### A.2.5.1 DWARF Expression Evaluation Context 1359 1360A DWARF expression is evaluated in a context that can include a number of 1361context elements. If multiple context elements are specified then they must be 1362self consistent or the result of the evaluation is undefined. The context 1363elements that can be specified are: 1364 13651. <i>A current result kind</i> 1366 1367 The kind of result required by the DWARF expression evaluation. If specified 1368 it can be a location description or a value. 1369 13702. <i>A current thread</i> 1371 1372 The target architecture thread identifier of the source program thread of 1373 execution for which a user presented expression is currently being 1374 evaluated. 1375 1376 It is required for operations that are related to target architecture 1377 threads. 1378 1379 <i>For example, the `DW_OP_regval_type` operation.</i> 1380 13813. <i>A current call frame</i> 1382 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 1388 call stack (see [6.4 Call Frame Information](#call-frame-information)). 1389 1390 It is required for operations that specify target architecture registers to 1391 support virtual unwinding of the call stack. 1392 1393 <i>For example, the `DW_OP_*reg*` operations.</i> 1394 1395 If specified, it must be an active call frame in the current thread. 1396 Otherwise the result is undefined. 1397 1398 If it is the currently executing call frame, then it is termed the top call 1399 frame. 1400 14014. <i>A current program location</i> 1402 1403 The target architecture program location corresponding to the current call 1404 frame of the current thread. 1405 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 1410 Information](#call-frame-information)). 1411 1412 It is required for the evaluation of location list expressions to select 1413 amongst multiple program location ranges. It is required for operations that 1414 specify target architecture registers to support virtual unwinding of the 1415 call stack (see [6.4 Call Frame Information](#call-frame-information)). 1416 1417 If specified: 1418 1419 - If the current call frame is the top call frame, it must be the current 1420 target architecture program location. 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. 1425 14265. <i>A current compilation unit</i> 1427 1428 The compilation unit debug information entry that contains the DWARF 1429 expression being evaluated. 1430 1431 It is required for operations that reference debug information associated 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 1434 space address size if no current target architecture is specified. 1435 1436 <i>For example, the `DW_OP_constx` and `DW_OP_addrx` operations.</i> 1437 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 1444 expression.</i> 1445 14466. <i>A current target architecture</i> 1447 1448 The target architecture. 1449 1450 It is required for operations that specify target architecture specific 1451 entities. 1452 1453 <i>For example, target architecture specific entities include DWARF register 1454 identifiers, DWARF address space identifiers, the default address space, and 1455 the address space address sizes.</i> 1456 1457 If specified: 1458 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. 1461 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. 1465 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 1472 number information entry (see [6.2 Line Number 1473 Information](#line-number-information)) corresponding to the current 1474 program location. 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`, 1479 `.debug_rnglists`, `.debug_rnglists.dwo`, `.debug_loclists`, and 1480 `.debug_loclists.dwo` sections. 1481 - Otherwise the result is undefined. 1482 14837. <i>A current object</i> 1484 1485 The location description of a program object. 1486 1487 It is required for the `DW_OP_push_object_address` operation. 1488 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 1492 expression.</i> 1493 1494 The result is undefined if the location description is invalid (see [2.5.3 1495 DWARF Location Description](#dwarf-location-description)). 1496 14978. <i>An initial stack</i> 1498 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 1501 evaluation of an operation expression starts. 1502 1503 Some debugger information entries have attributes that evaluate their DWARF 1504 expression value with initial stack entries. In all other cases the initial 1505 stack is empty. 1506 1507 The result is undefined if any location descriptions are invalid (see [2.5.3 1508 DWARF Location Description](#dwarf-location-description)). 1509 1510If the evaluation requires a context element that is not specified, then the 1511result of the evaluation is an error. 1512 1513<i>A DWARF expression for a location description may be able to be evaluated 1514without a thread, call frame, program location, or architecture context. For 1515example, the location of a global variable may be able to be evaluated without 1516such context. If the expression evaluates with an error then it may indicate the 1517variable has been optimized and so requires more context.</i> 1518 1519<i>The DWARF expression for call frame information (see [6.4 Call Frame 1520Information](#call-frame-information)) operations are restricted to those 1521that do not require the compilation unit context to be specified.</i> 1522 1523The DWARF is ill-formed if all the `address_size` fields in the headers of all 1524the entries in the `.debug_info`, `.debug_addr`, `.debug_line`, 1525`.debug_rnglists`, `.debug_rnglists.dwo`, `.debug_loclists`, and 1526`.debug_loclists.dwo` sections corresponding to any given program location do 1527not match. 1528 1529#### A.2.5.2 DWARF Expression Value 1530 1531A value has a type and a literal value. It can represent a literal value of any 1532supported base type of the target architecture. The base type specifies the 1533size, encoding, and endianity of the literal value. 1534 1535> NOTE: It may be desirable to add an implicit pointer base type encoding. It 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. 1541 1542There is a distinguished base type termed the generic type, which is an integral 1543type that has the size of an address in the target architecture default address 1544space, a target architecture defined endianity, and unspecified signedness. 1545 1546<i>The generic type is the same as the unspecified type used for stack 1547operations defined in DWARF Version 4 and before.</i> 1548 1549An integral type is a base type that has an encoding of `DW_ATE_signed`, 1550`DW_ATE_signed_char`, `DW_ATE_unsigned`, `DW_ATE_unsigned_char`, 1551`DW_ATE_boolean`, or any target architecture defined integral encoding in the 1552inclusive range `DW_ATE_lo_user` to `DW_ATE_hi_user`. 1553 1554> NOTE: It is unclear if `DW_ATE_address` is an integral type. GDB does not seem 1555> to consider it as integral. 1556 1557#### A.2.5.3 DWARF Location Description 1558 1559<i>Debugging information must provide consumers a way to find the location of 1560program variables, determine the bounds of dynamic arrays and strings, and 1561possibly to find the base address of a subprogram's call frame or the return 1562address of a subprogram. Furthermore, to meet the needs of recent computer 1563architectures and optimization techniques, debugging information must be able to 1564describe the location of an object whose location changes over the object's 1565lifetime, and may reside at multiple locations simultaneously during parts of an 1566object's lifetime.</i> 1567 1568Information about the location of program objects is provided by location 1569descriptions. 1570 1571Location descriptions can consist of one or more single location descriptions. 1572 1573A single location description specifies the location storage that holds a 1574program object and a position within the location storage where the program 1575object starts. The position within the location storage is expressed as a bit 1576offset relative to the start of the location storage. 1577 1578A location storage is a linear stream of bits that can hold values. Each 1579location storage has a size in bits and can be accessed using a zero-based bit 1580offset. The ordering of bits within a location storage uses the bit numbering 1581and direction conventions that are appropriate to the current language on the 1582target architecture. 1583 1584There are five kinds of location storage: 1585 15861. <i>memory location storage</i> 1587 1588 Corresponds to the target architecture memory address spaces. 1589 15902. <i>register location storage</i> 1591 1592 Corresponds to the target architecture registers. 1593 15943. <i>implicit location storage</i> 1595 1596 Corresponds to fixed values that can only be read. 1597 15984. <i>undefined location storage</i> 1599 1600 Indicates no value is available and therefore cannot be read or written. 1601 16025. <i>composite location storage</i> 1603 1604 Allows a mixture of these where some bits come from one location storage and 1605 some from another location storage, or from disjoint parts of the same 1606 location storage. 1607 1608> NOTE: It may be better to add an implicit pointer location storage kind used 1609> by the `DW_OP_implicit_pointer` operation. It would specify the debugger 1610> information entry and byte offset provided by the operations. 1611 1612<i>Location descriptions are a language independent representation of addressing 1613rules.</i> 1614 1615- <i>They can be the result of evaluating a debugger information entry attribute 1616 that specifies an operation expression of arbitrary complexity. In this usage 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 1619 Entries](#lexical-block-entries)) that owns it, and it does not move during 1620 its lifetime.</i> 1621 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 1624 location of an object that has a limited lifetime, changes its location during 1625 its lifetime, or has multiple locations over part or all of its lifetime.</i> 1626 1627If a location description has more than one single location description, the 1628DWARF expression is ill-formed if the object value held in each single location 1629description's position within the associated location storage is not the same 1630value, except for the parts of the value that are uninitialized. 1631 1632<i>A location description that has more than one single location description can 1633only be created by a location list expression that has overlapping program 1634location ranges, or certain expression operations that act on a location 1635description that has more than one single location description. There are no 1636operation expression operations that can directly create a location description 1637with more than one single location description.</i> 1638 1639<i>A location description with more than one single location description can be 1640used to describe objects that reside in more than one piece of storage at the 1641same time. An object may have more than one location as a result of 1642optimization. For example, a value that is only read may be promoted from memory 1643to a register for some region of code, but later code may revert to reading the 1644value from memory as the register may be used for other purposes. For the code 1645region where the value is in a register, any change to the object value must be 1646made in both the register and the memory so both regions of code will read the 1647updated value.</i> 1648 1649<i>A consumer of a location description with more than one single location 1650description can read the object's value from any of the single location 1651descriptions (since they all refer to location storage that has the same value), 1652but must write any changed value to all the single location descriptions.</i> 1653 1654Updating a location description L by a bit offset B is defined as adding the 1655value of B to the bit offset of each single location description SL of L. It is 1656an evaluation error if the updated bit offset of any SL is less than 0 or 1657greater than or equal to the size of the location storage specified by SL. 1658 1659The evaluation of an expression may require context elements to create a 1660location description. If such a location description is accessed, the storage it 1661denotes is that associated with the context element values specified when the 1662location description was created, which may differ from the context at the time 1663it is accessed. 1664 1665<i>For example, creating a register location description requires the thread 1666context: the location storage is for the specified register of that thread. 1667Creating a memory location description for an address space may required a 1668thread context: the location storage is the memory associated with that 1669thread.</i> 1670 1671If any of the context elements required to create a location description change, 1672the location description becomes invalid and accessing it is undefined. 1673 1674<i>Examples of context that can invalidate a location description are:</i> 1675 1676- <i>The thread context is required and execution causes the thread to 1677 terminate.</i> 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 1682 entry that applies.</i> 1683- <i>An operation uses call frame information:</i> 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 1687 occurs.</i> 1688 1689<i>A DWARF expression can be used to compute a location description for an 1690object. A subsequent DWARF expression evaluation can be given the object 1691location description as the object context or initial stack context to compute a 1692component of the object. The final result is undefined if the object location 1693description becomes invalid between the two expression evaluations.</i> 1694 1695A change of a thread's program location may not make a location description 1696invalid, yet may still render it as no longer meaningful. Accessing such a 1697location description, or using it as the object context or initial stack context 1698of an expression evaluation, may produce an undefined result. 1699 1700<i>For example, a location description may specify a register that no longer 1701holds the intended program object after a program location change. One way to 1702avoid such problems is to recompute location descriptions associated with 1703threads when their program locations change.</i> 1704 1705#### A.2.5.4 DWARF Operation Expressions 1706 1707An operation expression is comprised of a stream of operations, each consisting 1708of an opcode followed by zero or more operands. The number of operands is 1709implied by the opcode. 1710 1711Operations represent a postfix operation on a simple stack machine. Each stack 1712entry can hold either a value or a location description. Operations can act on 1713entries on the stack, including adding entries and removing entries. If the kind 1714of a stack entry does not match the kind required by the operation and is not 1715implicitly convertible to the required kind 1716(see [2.5.4.4.3 Memory Location Description Operations](#memory-location-description-operations)), 1717then the DWARF operation expression is ill-formed. 1718 1719Evaluation of an operation expression starts with an empty stack on which the 1720entries from the initial stack provided by the context are pushed in the order 1721provided. Then the operations are evaluated, starting with the first operation 1722of the stream. Evaluation continues until either an operation has an evaluation 1723error, or until one past the last operation of the stream is reached. 1724 1725The result of the evaluation is: 1726 1727- If an operation has an evaluation error, or an operation evaluates an 1728 expression that has an evaluation error, then the result is an evaluation 1729 error. 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 1732 undefined location description. 1733 1734 <i>This rule is for backwards compatibility with DWARF Version 5 which uses 1735 an empty operation expression for this purpose.</i> 1736 1737 - If the top stack entry is a location description, or can be converted to one 1738 (see [2.5.4.4.3 Memory Location Description Operations](#memory-location-description-operations)), 1739 then the result is that, possibly converted, location description. Any other entries on the 1740 stack are discarded. 1741 - Otherwise the DWARF expression is ill-formed. 1742 1743 > NOTE: Could define this case as returning an implicit location description 1744 > as if the `DW_OP_implicit` operation is performed. 1745 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 1748 [2.5.4.4.3 Memory Location Description Operations](#memory-location-description-operations)), 1749 then the result is that, possibly converted, value. Any other entries on the stack are 1750 discarded. 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 1754 undefined location description. 1755 1756 <i>This rule is for backwards compatibility with DWARF Version 5 which uses 1757 an empty operation expression for this purpose.</i> 1758 1759 > NOTE: This rule is consistent with the rule above for when a location 1760 > description is requested. However, GDB appears to report this as an error 1761 > and no GDB tests appear to cause an empty stack for this case. 1762 1763 - Otherwise, the top stack entry is returned. Any other entries on the stack 1764 are discarded. 1765 1766An operation expression is encoded as a byte block with some form of prefix that 1767specifies the byte count. It can be used: 1768 1769- as the value of a debugging information entry attribute that is encoded using 1770 class `exprloc` (see [7.5.5 Classes and Forms](#classes-and-forms)), 1771- as the operand to certain operation expression operations, 1772- as the operand to certain call frame information operations (see [6.4 Call 1773 Frame Information](#call-frame-information)), 1774- and in location list entries (see [2.5.5 DWARF Location List 1775 Expressions](#dwarf-location-list-expressions)). 1776 1777##### A.2.5.4.1 Stack Operations 1778 1779> NOTE: This section replaces DWARF Version 5 section 2.5.1.3. 1780 1781The following operations manipulate the DWARF stack. Operations that index the 1782stack assume that the top of the stack (most recently added entry) has index 0. 1783They allow the stack entries to be either a value or location description. 1784 1785If any stack entry accessed by a stack operation is an incomplete composite 1786location description (see [2.5.4.4.6 Composite Location Description Operations] 1787(#composite-location-description-operations)), then the DWARF expression is ill-formed. 1788 1789> NOTE: These operations now support stack entries that are values and location 1790> descriptions. 1791 1792> NOTE: If it is desired to also make them work with incomplete composite 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 1797> storage they specify independently. 1798 17991. `DW_OP_dup` 1800 1801 `DW_OP_dup` duplicates the stack entry at the top of the stack. 1802 18032. `DW_OP_drop` 1804 1805 `DW_OP_drop` pops the stack entry at the top of the stack and discards it. 1806 18073. `DW_OP_pick` 1808 1809 `DW_OP_pick` has a single unsigned 1-byte operand that represents an index 1810 I. A copy of the stack entry with index I is pushed onto the stack. 1811 18124. `DW_OP_over` 1813 1814 `DW_OP_over` pushes a copy of the entry with index 1. 1815 1816 <i>This is equivalent to a `DW_OP_pick 1` operation.</i> 1817 18185. `DW_OP_swap` 1819 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. 1823 18246. `DW_OP_rot` 1825 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. 1829 1830<i>Examples illustrating many of these stack operations are found in Appendix 1831D.1.2 on page 289.</i> 1832 1833##### A.2.5.4.2 Control Flow Operations 1834 1835> NOTE: This section replaces DWARF Version 5 section 2.5.1.5. 1836 1837The following operations provide simple control of the flow of a DWARF operation 1838expression. 1839 18401. `DW_OP_nop` 1841 1842 `DW_OP_nop` is a place holder. It has no effect on the DWARF stack entries. 1843 18442. `DW_OP_le`, `DW_OP_ge`, `DW_OP_eq`, `DW_OP_lt`, `DW_OP_gt`, 1845 `DW_OP_ne` 1846 1847 > NOTE: The same as in DWARF Version 5 section 2.5.1.5. 1848 18493. `DW_OP_skip` 1850 1851 `DW_OP_skip` is an unconditional branch. Its single operand is a 2-byte 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. 1855 1856 If the updated position is at one past the end of the last operation, then 1857 the operation expression evaluation is complete. 1858 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. 1862 18634. `DW_OP_bra` 1864 1865 `DW_OP_bra` is a conditional branch. Its single operand is a 2-byte signed 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. 1870 1871 If the updated position is at one past the end of the last operation, then 1872 the operation expression evaluation is complete. 1873 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. 1877 18785. `DW_OP_call2, DW_OP_call4, DW_OP_call_ref` 1879 1880 `DW_OP_call2`, `DW_OP_call4`, and `DW_OP_call_ref` perform DWARF procedure 1881 calls during evaluation of a DWARF operation expression. 1882 1883 `DW_OP_call2` and `DW_OP_call4`, have one operand that is, respectively, a 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 1886 compilation unit. 1887 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. 1893 1894 > NOTE: DWARF Version 5 states that DR can be an offset in a `.debug_info` 1895 > section other than the one that contains the current compilation unit. It 1896 > states that relocation of references from one executable or shared object 1897 > file to another must be performed by the consumer. But given that DR is 1898 > defined as an offset in a `.debug_info` section this seems impossible. If 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 1901 > reference a debug information in another executable or shared object. 1902 > 1903 > In ELF the `.debug_info` section is in a non-`PT_LOAD` segment so standard 1904 > dynamic relocations cannot be used. But even if they were loaded segments 1905 > and dynamic relocations were used, DR would need to be the address of D, 1906 > not an offset in a `.debug_info` section. That would also need DR to be 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 1911 > unit. 1912 > 1913 > GDB only interprets DR as an offset in the `.debug_info` section that 1914 > contains the current compilation unit. 1915 > 1916 > This comment also applies to `DW_OP_implicit_pointer`. 1917 1918 <i>Operand interpretation of `DW_OP_call2`, `DW_OP_call4`, and 1919 `DW_OP_call_ref` is exactly like that for `DW_FORM_ref2`, `DW_FORM_ref4`, 1920 and `DW_FORM_ref_addr`, respectively.</i> 1921 1922 The call operation is evaluated by: 1923 1924 - If D has a `DW_AT_location` attribute that is encoded as a `exprloc` that 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. 1936 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 1940 calling and called expressions.</i> 1941 1942 - If D has a `DW_AT_location` attribute that is encoded as a `loclist` or 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. 1948 1949 > NOTE: This rule avoids having to define how to execute a matched 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 1952 > location description for a variable or formal parameter which may use a 1953 > location list expression. 1954 > 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 1957 > specified location list expression E' matches a single location list 1958 > entry with operation expression E, the same as the `exprloc` case and 1959 > evaluate on the same stack. 1960 > 1961 > But this is not attractive as if the attribute is for a variable that 1962 > happens to end with a non-singleton stack, it will not simply put a 1963 > location description on the stack. Presumably the intent of using 1964 > `DW_OP_call*` on a variable or formal parameter debugger information 1965 > entry is to push just one location description on the stack. That 1966 > location description may have more than one single location description. 1967 > 1968 > The previous rule for `exprloc` also has the same problem, as normally a 1969 > variable or formal parameter location expression may leave multiple 1970 > entries on the stack and only return the top entry. 1971 > 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. 1976 > 1977 > So, it feels like `DW_OP_call*` should both support pushing a location 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. 1980 > Being able to specify a different operation expression for different 1981 > program locations seems a desirable feature to retain. 1982 > 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 1985 > `DW_AT_location` attribute expression is always executed separately and 1986 > pushes a location description (that may have multiple single location 1987 > descriptions), and the `DW_AT_proc` attribute expression is always 1988 > executed on the same stack and can leave anything on the stack. 1989 > 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 1995 > location list does not match exactly one location list entry and a 1996 > default entry is required. These forms indicate explicitly that the 1997 > matched single operation expression must be executed on the same stack. 1998 > This is better than ad hoc special rules for `loclistproc` and 1999 > `loclistsptrproc` which are currently clearly defined to always return a 2000 > location description. The producer then explicitly indicates the intent 2001 > through the attribute classes. 2002 > 2003 > Such a change would be a breaking change for how GDB implements 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 2007 > other features. 2008 > 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 2011 > `DW_AT_location` attribute of a `DW_TAG_dwarf_procedure` debugging 2012 > information entry. The DWARF would be ill-formed if E is a location list 2013 > expression that does not match exactly one location list entry. In all 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. 2019 2020 - If D has a `DW_AT_const_value` attribute with a value V, then it is as if 2021 a `DW_OP_implicit_value V` operation was executed. 2022 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 2026 `DW_OP_implicit_pointer` operation.</i> 2027 2028 > NOTE: Alternatively, could deprecate using `DW_AT_const_value` for 2029 > `DW_TAG_variable` and `DW_TAG_formal_parameter` debugger information 2030 > entries that are constants and instead use `DW_AT_location` with an 2031 > operation expression that results in a location description with one 2032 > implicit location description. Then this rule would not be required. 2033 2034 - Otherwise, there is no effect and no changes are made to the stack. 2035 2036 > NOTE: In DWARF Version 5, if D does not have a `DW_AT_location` then 2037 > `DW_OP_call*` is defined to have no effect. It is unclear that this is 2038 > the right definition as a producer should be able to rely on using 2039 > `DW_OP_call*` to get a location description for any 2040 > non-`DW_TAG_dwarf_procedure` debugging information entries. Also, the 2041 > producer should not be creating DWARF with `DW_OP_call*` to a 2042 > `DW_TAG_dwarf_procedure` that does not have a `DW_AT_location` 2043 > attribute. So, should this case be defined as an ill-formed DWARF 2044 > expression? 2045 2046 <i>The `DW_TAG_dwarf_procedure` debugging information entry can be used to 2047 define DWARF procedures that can be called.</i> 2048 2049##### A.2.5.4.3 Value Operations 2050 2051This section describes the operations that push values on the stack. 2052 2053Each value stack entry has a type and a literal value. It can represent a 2054literal value of any supported base type of the target architecture. The base 2055type specifies the size, encoding, and endianity of the literal value. 2056 2057The base type of value stack entries can be the distinguished generic type. 2058 2059###### A.2.5.4.3.1 Literal Operations 2060 2061> NOTE: This section replaces DWARF Version 5 section 2.5.1.1. 2062 2063The following operations all push a literal value onto the DWARF stack. 2064 2065Operations other than `DW_OP_const_type` push a value V with the generic type. 2066If V is larger than the generic type, then V is truncated to the generic type 2067size and the low-order bits used. 2068 20691. `DW_OP_lit0`, `DW_OP_lit1`, ..., `DW_OP_lit31` 2070 2071 `DW_OP_lit<N>` operations encode an unsigned literal value N from 0 through 2072 31, inclusive. They push the value N with the generic type. 2073 20742. `DW_OP_const1u`, `DW_OP_const2u`, `DW_OP_const4u`, `DW_OP_const8u` 2075 2076 `DW_OP_const<N>u` operations have a single operand that is a 1, 2, 4, or 2077 8-byte unsigned integer constant U, respectively. They push the value U with 2078 the generic type. 2079 20803. `DW_OP_const1s`, `DW_OP_const2s`, `DW_OP_const4s`, `DW_OP_const8s` 2081 2082 `DW_OP_const<N>s` operations have a single operand that is a 1, 2, 4, or 2083 8-byte signed integer constant S, respectively. They push the value S with 2084 the generic type. 2085 20864. `DW_OP_constu` 2087 2088 `DW_OP_constu` has a single unsigned LEB128 integer operand N. It pushes the 2089 value N with the generic type. 2090 20915. `DW_OP_consts` 2092 2093 `DW_OP_consts` has a single signed LEB128 integer operand N. It pushes the 2094 value N with the generic type. 2095 20966. `DW_OP_constx` 2097 2098 `DW_OP_constx` has a single unsigned LEB128 integer operand that represents 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. 2103 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 2106 relocatable address (for example, offsets to thread-local storage).</i> 2107 21087. `DW_OP_const_type` 2109 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. 2115 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 2118 D. 2119 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. 2123 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` 2127 section.</i> 2128 2129###### A.2.5.4.3.2 Arithmetic and Logical Operations 2130 2131> NOTE: This section is the same as DWARF Version 5 section 2.5.1.4. 2132 2133###### A.2.5.4.3.3 Type Conversion Operations 2134 2135> NOTE: This section is the same as DWARF Version 5 section 2.5.1.6. 2136 2137###### A.2.5.4.3.4 Special Value Operations 2138 2139> NOTE: This section replaces parts of DWARF Version 5 sections 2.5.1.2, 2140 2.5.1.3, and 2.5.1.7. 2141 2142There are these special value operations currently defined: 2143 21441. `DW_OP_regval_type` 2145 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. 2151 2152 The operation is equivalent to performing `DW_OP_regx R; DW_OP_deref_type 2153 DR`. 2154 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 2158 > simply interpreted as a value of T. If a conversion is wanted it can be 2159 > done explicitly using a `DW_OP_convert` operation. 2160 > 2161 > GDB has a per register hook that allows a target specific conversion on a 2162 > register by register basis. It defaults to truncation of bigger registers. 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 2165 > form of conversion, including a larger result type, it could always 2166 > explicitly use the `DW_OP_convert` operation. 2167 > 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 2171 > any test failures in common architectures (except an illegal hand written 2172 > assembly test). If a target architecture requires this behavior, these 2173 > extensions allow a composite location description to be used to combine 2174 > multiple registers. 2175 21762. `DW_OP_deref` 2177 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 2181 generic type. 2182 2183 The operation is equivalent to performing `DW_OP_deref_type S, DR`. 2184 21853. `DW_OP_deref_size` 2186 2187 `DW_OP_deref_size` has a single 1-byte unsigned integral constant that 2188 represents a byte result size S. 2189 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 2194 compilation unit for a base type T. 2195 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 2198 > byte size. It does allow S to be arbitrarily large. Should S be restricted 2199 > to the size of the generic type rounded up to a multiple of 8? 2200 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. 2204 22054. `DW_OP_deref_type` 2206 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. 2211 2212 TS is the bit size of the type T. 2213 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> 2217 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 2221 > and bit size. 2222 2223 It pops one stack entry that must be a location description L. 2224 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. 2227 2228 <i>If L, or the location description of any composite location description 2229 part that is a subcomponent of L, has more than one single location 2230 description, then any one of them can be selected as they are required to 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> 2236 2237 V is pushed on the stack with the type T. 2238 2239 > NOTE: This definition makes it an evaluation error if L is a register 2240 > location description that has less than TS bits remaining in the register 2241 > storage. Particularly since these extensions extend location descriptions 2242 > to have a bit offset, it would be odd to define this as performing sign 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 2245 > implementation for `DW_OP_deref_type`. 2246 > 2247 > These extensions define `DW_OP_*breg*` in terms of `DW_OP_regval_type`. 2248 > `DW_OP_regval_type` is defined in terms of `DW_OP_regx`, which uses a 0 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*`. 2252 2253 The DWARF is ill-formed if D is not in the current compilation unit, D is 2254 not a `DW_TAG_base_type` debugging information entry, or if TS divided by 8 2255 (the byte size) and rounded up to a whole number is not equal to S. 2256 2257 > NOTE: This definition allows the base type to be a bit size since there 2258 > seems no reason to restrict it. 2259 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 2262 location storage LS specified by any single location description SL of L. 2263 2264 See [2.5.4.4.5 Implicit Location Description Operations](#implicit-location-description-operations) 2265 for special rules concerning implicit location descriptions created by the 2266 `DW_OP_implicit_pointer` operation. 2267 22685. `DW_OP_xderef` 2269 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 2272 value that represents a target architecture specific address space 2273 identifier AS. 2274 2275 The address size S is defined as the address bit size of the target 2276 architecture specific address space that corresponds to AS. 2277 2278 A is adjusted to S bits by zero extending if necessary, and then treating 2279 the least significant S bits as an unsigned value A'. 2280 2281 It creates a location description L with one memory location description SL. 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). 2284 2285 If AS is an address space that is specific to context elements, then LS 2286 corresponds to the location storage associated with the current context. 2287 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> 2293 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. 2296 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. 2300 23016. `DW_OP_xderef_size` 2302 2303 `DW_OP_xderef_size` has a single 1-byte unsigned integral constant that 2304 represents a byte result size S. 2305 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 2308 value that represents a target architecture specific address space 2309 identifier AS. 2310 2311 It creates a location description L as described for `DW_OP_xderef`. 2312 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. 2316 23177. `DW_OP_xderef_type` 2318 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. 2324 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 2327 represents a target architecture specific address space identifier AS. 2328 2329 It creates a location description L as described for `DW_OP_xderef`. 2330 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. 2334 23358. `DW_OP_entry_value` <i>Deprecated</i> 2336 2337 `DW_OP_entry_value` pushes the value of an expression that is evaluated in 2338 the context of the calling frame. 2339 2340 <i>It may be used to determine the value of arguments on entry to the 2341 current call frame provided they are not clobbered.</i> 2342 2343 It has two operands. The first is an unsigned LEB128 integer S. The second 2344 is a block of bytes, with a length equal S, interpreted as a DWARF operation 2345 expression E. 2346 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 2352 frame information (see [6.4 Call Frame 2353 Information](#call-frame-information)). 2354 2355 If the result of E is a location description L (see [2.5.4.4.4 Register 2356 Location Description 2357 Operations](#register-location-description-operations)), and the last 2358 operation executed by E is a `DW_OP_reg*` for register R with a target 2359 architecture specific base type of T, then the contents of the register are 2360 retrieved as if a `DW_OP_deref_type DR` operation was performed where DR is 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. 2363 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> 2366 2367 > NOTE: It is unclear how this provides a more compact expression, as 2368 > `DW_OP_regval_type` could be used which is marginally larger. 2369 2370 If the result of E is a value V, then V is pushed on the stack. 2371 2372 Otherwise, the DWARF expression is ill-formed. 2373 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 2376 `DW_TAG_call_site_parameter` debugger information entry for call sites that 2377 has `DW_AT_call_value`, `DW_AT_call_data_location`, and 2378 `DW_AT_call_data_value` attributes that provide DWARF expressions to compute 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 2381 unwound.</i> 2382 2383 > NOTE: GDB only implements `DW_OP_entry_value` when E is exactly 2384 > `DW_OP_reg*` or `DW_OP_breg*; DW_OP_deref*`. 2385 2386##### A.2.5.4.4 Location Description Operations 2387 2388This section describes the operations that push location descriptions on the 2389stack. 2390 2391###### A.2.5.4.4.1 General Location Description Operations 2392 2393> NOTE: This section replaces part of DWARF Version 5 section 2.5.1.3. 2394 23951. `DW_OP_push_object_address` 2396 2397 `DW_OP_push_object_address` pushes the location description L of the current 2398 object. 2399 2400 <i>This object may correspond to an independent variable that is part of a 2401 user presented expression that is being evaluated. The object location 2402 description may be determined from the variable's own debugging information 2403 entry or it may be a component of an array, structure, or class whose 2404 address has been dynamically determined by an earlier step during user 2405 expression evaluation.</i> 2406 2407 <i>This operation provides explicit functionality (especially for arrays 2408 involving descriptors) that is analogous to the implicit push of the base 2409 location description of a structure prior to evaluation of a 2410 `DW_AT_data_member_location` to access a data member of a structure.</i> 2411 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`. 2414 > 2415 > Or this operation could be used instead of needing to specify an initial 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. 2419 > If this were done, ``DW_AT_use_location`` would require a 2420 > ``DW_OP_push_object2_address`` operation for the second object. 2421 > 2422 > Or a more general way to pass an arbitrary number of arguments in and an 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 2426 > allowing a specific number of arguments passed in and returned to be 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. 2432 > 2433 > The only attribute that specifies a current object is 2434 > `DW_AT_data_location` so the non-normative text seems to overstate how 2435 > this is being used. Or are there other attributes that need to state they 2436 > pass an object? 2437 2438###### A.2.5.4.4.2 Undefined Location Description Operations 2439 2440> NOTE: This section replaces DWARF Version 5 section 2.6.1.1.1. 2441 2442<i>The undefined location storage represents a piece or all of an object that is 2443present in the source but not in the object code (perhaps due to optimization). 2444Neither reading nor writing to the undefined location storage is meaningful.</i> 2445 2446An undefined location description specifies the undefined location storage. 2447There is no concept of the size of the undefined location storage, nor of a bit 2448offset for an undefined location description. The `DW_OP_*piece` operations can 2449implicitly specify an undefined location description, allowing any size and 2450offset to be specified, and results in a part with all undefined bits. 2451 2452###### A.2.5.4.4.3 Memory Location Description Operations 2453 2454> NOTE: This section replaces parts of DWARF Version 5 section 2.5.1.1, 2.5.1.2, 2455> 2.5.1.3, and 2.6.1.1.2. 2456 2457Each of the target architecture specific address spaces has a corresponding 2458memory location storage that denotes the linear addressable memory of that 2459address space. The size of each memory location storage corresponds to the range 2460of the addresses in the corresponding address space. 2461 2462<i>It is target architecture defined how address space location storage maps to 2463target architecture physical memory. For example, they may be independent 2464memory, or more than one location storage may alias the same physical memory 2465possibly at different offsets and with different interleaving. The mapping may 2466also be dictated by the source language address classes.</i> 2467 2468A memory location description specifies a memory location storage. The bit 2469offset corresponds to a bit position within a byte of the memory. Bits accessed 2470using a memory location description, access the corresponding target 2471architecture memory starting at the bit position within the byte specified by 2472the bit offset. 2473 2474A memory location description that has a bit offset that is a multiple of 8 (the 2475byte size) is defined to be a byte address memory location description. It has a 2476memory byte address A that is equal to the bit offset divided by 8. 2477 2478A memory location description that does not have a bit offset that is a multiple 2479of 8 (the byte size) is defined to be a bit field memory location description. 2480It has a bit position B equal to the bit offset modulo 8, and a memory byte 2481address A equal to the bit offset minus B that is then divided by 8. 2482 2483The address space AS of a memory location description is defined to be the 2484address space that corresponds to the memory location storage associated with 2485the memory location description. 2486 2487A location description that is comprised of one byte address memory location 2488description SL is defined to be a memory byte address location description. It 2489has a byte address equal to A and an address space equal to AS of the 2490corresponding SL. 2491 2492`DW_ASPACE_none` is defined as the target architecture default address space. 2493 2494If a stack entry is required to be a location description, but it is a value V 2495with the generic type, then it is implicitly converted to a location description 2496L with one memory location description SL. SL specifies the memory location 2497storage that corresponds to the target architecture default address space with a 2498bit offset equal to V scaled by 8 (the byte size). 2499 2500> NOTE: If it is wanted to allow any integral type value to be implicitly 2501> converted to a memory location description in the target architecture default 2502> address space: 2503> 2504> > If a stack entry is required to be a location description, but is a value V 2505> > with an integral type, then it is implicitly converted to a location 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 2509> > are treated as an unsigned value to be used as an address A. SL specifies 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). 2512> 2513> The implicit conversion could also be defined as target architecture specific. 2514> For example, GDB checks if V is an integral type. If it is not it gives an 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. 2519 2520If a stack entry is required to be a location description, but it is an implicit 2521pointer value IPV with the target architecture default address space, then it is 2522implicitly converted to a location description with one single location 2523description specified by IPV. See 2524[2.5.4.4.5 Implicit Location Description Operations](#implicit-location-description-operations). 2525 2526If a stack entry is required to be a value, but it is a location description L 2527with one memory location description SL in the target architecture default 2528address space with a bit offset B that is a multiple of 8, then it is implicitly 2529converted to a value equal to B divided by 8 (the byte size) with the generic 2530type. 2531 25321. `DW_OP_addr` 2533 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. 2536 2537 It pushes a location description L with one memory location description SL 2538 on the stack. SL specifies the memory location storage corresponding to the 2539 target architecture default address space with a bit offset equal to A 2540 scaled by 8 (the byte size). 2541 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> 2546 25472. `DW_OP_addrx` 2548 2549 `DW_OP_addrx` has a single unsigned LEB128 integer operand that represents a 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. 2553 2554 It pushes a location description L with one memory location description SL 2555 on the stack. SL specifies the memory location storage corresponding to the 2556 target architecture default address space with a bit offset equal to A 2557 scaled by 8 (the byte size). 2558 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> 2563 25643. `DW_OP_form_tls_address` 2565 2566 `DW_OP_form_tls_address` pops one stack entry that must be an integral type 2567 value and treats it as a thread-local storage address TA. 2568 2569 It pushes a location description L with one memory location description SL 2570 on the stack. SL is the target architecture specific memory location 2571 description that corresponds to the thread-local storage address TA. 2572 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 2577 expression is used. 2578 2579 <i>Some implementations of C, C++, Fortran, and other languages, support a 2580 thread-local storage class. Variables with this storage class have distinct 2581 values and addresses in distinct threads, much as automatic variables have 2582 distinct values and addresses in each subprogram invocation. Typically, 2583 there is a single block of storage containing all thread-local variables 2584 declared in the main executable, and a separate block for the variables 2585 declared in each shared library. Each thread-local variable can then be 2586 accessed in its block using an identifier. This identifier is typically a 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 2591 describe using ordinary DWARF location descriptions. Instead of forcing 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> 2595 25964. `DW_OP_call_frame_cfa` 2597 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 2601 Information](#call-frame-information). 2602 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 2605 using a location list expression, in some cases this would require an 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 2608 information is present, then it already encodes such changes, and it is 2609 space efficient to reference that using the `DW_OP_call_frame_cfa` 2610 operation.</i> 2611 26125. `DW_OP_fbreg` 2613 2614 `DW_OP_fbreg` has a single signed LEB128 integer operand that represents a 2615 byte displacement B. 2616 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 2620 [3.3.5 Low-Level Information](#low-level-information). 2621 2622 The location description L is updated by bit offset B scaled by 8 (the byte 2623 size) and pushed on the stack. 2624 26256. `DW_OP_breg0`, `DW_OP_breg1`, ..., `DW_OP_breg31` 2626 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. 2630 2631 They have a single signed LEB128 integer operand that represents a byte 2632 displacement B. 2633 2634 The address space identifier AS is defined as the one corresponding to the 2635 target architecture specific default address space. 2636 2637 The address size S is defined as the address bit size of the target 2638 architecture specific address space corresponding to AS. 2639 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 2644 significant S bits are treated as an unsigned value to be used as an address 2645 A. 2646 2647 They push a location description L comprising one memory location 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). 2650 26517. `DW_OP_bregx` 2652 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 2655 represents a byte displacement B. 2656 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. 2659 2660###### A.2.5.4.4.4 Register Location Description Operations 2661 2662> NOTE: This section replaces DWARF Version 5 section 2.6.1.1.3. 2663 2664There is a register location storage that corresponds to each of the target 2665architecture registers. The size of each register location storage corresponds 2666to the size of the corresponding target architecture register. 2667 2668A register location description specifies a register location storage. The bit 2669offset corresponds to a bit position within the register. Bits accessed using a 2670register location description access the corresponding target architecture 2671register starting at the specified bit offset. 2672 26731. `DW_OP_reg0`, `DW_OP_reg1`, ..., `DW_OP_reg31` 2674 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. 2678 2679 The operation is equivalent to performing `DW_OP_regx R`. 2680 26812. `DW_OP_regx` 2682 2683 `DW_OP_regx` has a single unsigned LEB128 integer operand that represents a 2684 target architecture register number R. 2685 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. 2690 2691 If the current call frame is not the top call frame, call frame information 2692 (see [6.4 Call Frame Information](#call-frame-information)) is used to 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 2695 location description L is pushed. 2696 2697 <i>Note that if call frame information is used, the resulting location 2698 description may be register, memory, or undefined.</i> 2699 2700 <i>An implementation may evaluate the call frame information immediately, or 2701 may defer evaluation until L is accessed by an operation. If evaluation is 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> 2705 2706<i>These operations obtain a register location. To fetch the contents of a 2707register, it is necessary to use `DW_OP_regval_type`, use one of the 2708`DW_OP_breg*` register-based addressing operations, or use `DW_OP_deref*` on a 2709register location description.</i> 2710 2711###### A.2.5.4.4.5 Implicit Location Description Operations 2712 2713> NOTE: This section replaces DWARF Version 5 section 2.6.1.1.4. 2714 2715Implicit location storage represents a piece or all of an object which has no 2716actual location in the program but whose contents are nonetheless known, either 2717as a constant or can be computed from other locations and values in the program. 2718 2719An implicit location description specifies an implicit location storage. The bit 2720offset corresponds to a bit position within the implicit location storage. Bits 2721accessed using an implicit location description, access the corresponding 2722implicit storage value starting at the bit offset. 2723 27241. `DW_OP_implicit_value` 2725 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 2728 length equal to S treated as a literal value V. 2729 2730 An implicit location storage LS is created with the literal value V and a 2731 size of S. 2732 2733 It pushes location description L with one implicit location description SL 2734 on the stack. SL specifies LS with a bit offset of 0. 2735 27362. `DW_OP_stack_value` 2737 2738 `DW_OP_stack_value` pops one stack entry that must be a value V. 2739 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. 2742 2743 It pushes a location description L with one implicit location description SL 2744 on the stack. SL specifies LS with a bit offset of 0. 2745 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> 2750 2751 See `DW_OP_implicit_pointer` (following) for special rules concerning 2752 implicit pointer values produced by dereferencing implicit location 2753 descriptions created by the `DW_OP_implicit_pointer` operation. 2754 2755 Note: Since location descriptions are allowed on the stack, the 2756 `DW_OP_stack_value` operation no longer terminates the DWARF operation 2757 expression execution as in DWARF Version 5. 2758 27593. `DW_OP_implicit_pointer` 2760 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 2763 to describe this value.</i> 2764 2765 <i>`DW_OP_implicit_pointer` specifies an object is a pointer to the target 2766 architecture default address space that cannot be represented as a real 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 2772 itself.</i> 2773 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 2779 LEB128 integer that represents a byte displacement B. 2780 2781 <i>Note that D might not be in the current compilation unit.</i> 2782 2783 <i>The first operand interpretation is exactly like that for 2784 `DW_FORM_ref_addr`.</i> 2785 2786 The address space identifier AS is defined as the one corresponding to the 2787 target architecture specific default address space. 2788 2789 The address size S is defined as the address bit size of the target 2790 architecture specific address space corresponding to AS. 2791 2792 An implicit location storage LS is created with the debugging information 2793 entry D, address space AS, and size of S. 2794 2795 It pushes a location description L that comprises one implicit location 2796 description SL on the stack. SL specifies LS with a bit offset of 0. 2797 2798 It is an evaluation error if a `DW_OP_deref*` operation pops a location 2799 description L', and retrieves S bits, such that any retrieved bits come from 2800 an implicit location storage that is the same as LS, unless both the 2801 following conditions are met: 2802 2803 1. All retrieved bits come from an implicit location description that 2804 refers to an implicit location storage that is the same as LS. 2805 2806 <i>Note that all bits do not have to come from the same implicit 2807 location description, as L' may involve composite location 2808 descriptions.</i> 2809 2810 2. The bits come from consecutive ascending offsets within their respective 2811 implicit location storage. 2812 2813 <i>These rules are equivalent to retrieving the complete contents of LS.</i> 2814 2815 If both the above conditions are met, then the value V pushed by the 2816 `DW_OP_deref*` operation is an implicit pointer value IPV with a target 2817 architecture specific address space of AS, a debugging information entry of 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 2820 specific integral type with a bit size equal to S. 2821 2822 If IPV is either implicitly converted to a location description (only done 2823 if AS is the target architecture default address space), then the resulting 2824 location description RL is: 2825 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. 2831 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 2834 `DW_OP_implicit_pointer` operation that created L.</i> 2835 2836 - If D has a `DW_AT_const_value` attribute, then an implicit location 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 2839 comprises one implicit location description SRL. SRL specifies RLS with a 2840 bit offset of 0. 2841 2842 > NOTE: If using `DW_AT_const_value` for variables and formal parameters 2843 > is deprecated and instead `DW_AT_location` is used with an implicit 2844 > location description, then this rule would not be required. 2845 2846 - Otherwise, it is an evaluation error. 2847 2848 The location description RL is updated by bit offset B scaled by 8 (the byte 2849 size). 2850 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. 2853 2854 It is an evaluation error if LS or IPV is accessed in any other manner. 2855 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. 2858 Similarly, for an implicit pointer value created by `DW_OP_deref*` and 2859 `DW_OP_stack_value`.</i> 2860 2861<i>Typically a `DW_OP_implicit_pointer` operation is used in a DWARF expression 2862E<sub>1</sub> of a `DW_TAG_variable` or `DW_TAG_formal_parameter` debugging 2863information entry D<sub>1</sub>'s `DW_AT_location` attribute. The debugging 2864information entry referenced by the `DW_OP_implicit_pointer` operation is 2865typically itself a `DW_TAG_variable` or `DW_TAG_formal_parameter` debugging 2866information entry D<sub>2</sub> whose `DW_AT_location` attribute gives a second 2867DWARF expression E<sub>2</sub>.</i> 2868 2869<i>D<sub>1</sub> and E<sub>1</sub> are describing the location of a pointer type 2870object. D<sub>2</sub> and E<sub>2</sub> are describing the location of the 2871object pointed to by that pointer object.</i> 2872 2873<i>However, D<sub>2</sub> may be any debugging information entry that contains a 2874`DW_AT_location` or `DW_AT_const_value` attribute (for example, 2875`DW_TAG_dwarf_procedure`). By using E<sub>2</sub>, a consumer can reconstruct 2876the value of the object when asked to dereference the pointer described by 2877E<sub>1</sub> which contains the `DW_OP_implicit_pointer` operation.</i> 2878 2879###### A.2.5.4.4.6 Composite Location Description Operations 2880 2881> NOTE: This section replaces DWARF Version 5 section 2.6.1.2. 2882 2883A composite location storage represents an object or value which may be 2884contained in part of another location storage or contained in parts of more than 2885one location storage. 2886 2887Each part has a part location description L and a part bit size S. L can have 2888one or more single location descriptions SL. If there are more than one SL then 2889that indicates that part is located in more than one place. The bits of each 2890place of the part comprise S contiguous bits from the location storage LS 2891specified by SL starting at the bit offset specified by SL. All the bits must be 2892within the size of LS or the DWARF expression is ill-formed. 2893 2894A composite location storage can have zero or more parts. The parts are 2895contiguous such that the zero-based location storage bit index will range over 2896each part with no gaps between them. Therefore, the size of a composite location 2897storage is the sum of the size of its parts. The DWARF expression is ill-formed 2898if the size of the contiguous location storage is larger than the size of the 2899memory location storage corresponding to the largest target architecture 2900specific address space. 2901 2902A composite location description specifies a composite location storage. The bit 2903offset corresponds to a bit position within the composite location storage. 2904 2905There are operations that create a composite location storage. 2906 2907There are other operations that allow a composite location storage to be 2908incrementally created. Each part is created by a separate operation. There may 2909be one or more operations to create the final composite location storage. A 2910series of such operations describes the parts of the composite location storage 2911that are in the order that the associated part operations are executed. 2912 2913To support incremental creation, a composite location storage can be in an 2914incomplete state. When an incremental operation operates on an incomplete 2915composite location storage, it adds a new part. 2916 2917A composite location description that specifies a composite location storage 2918that is incomplete is termed an incomplete composite location description. A 2919composite location description that specifies a composite location storage that 2920is complete is termed a complete composite location description. 2921 2922If the top stack entry is a location description that has one incomplete 2923composite location description SL after the execution of an operation expression 2924has completed, SL is converted to a complete composite location description. 2925 2926<i>Note that this conversion does not happen after the completion of an 2927operation expression that is evaluated on the same stack by the `DW_OP_call*` 2928operations. Such executions are not a separate evaluation of an operation 2929expression, but rather the continued evaluation of the same operation expression 2930that contains the `DW_OP_call*` operation.</i> 2931 2932If a stack entry is required to be a location description L, but L has an 2933incomplete composite location description, then the DWARF expression is 2934ill-formed. The exception is for the operations involved in incrementally 2935creating a composite location description as described below. 2936 2937<i>Note that a DWARF operation expression may arbitrarily compose composite 2938location descriptions from any other location description, including those that 2939have multiple single location descriptions, and those that have composite 2940location descriptions.</i> 2941 2942<i>The incremental composite location description operations are defined to be 2943compatible with the definitions in DWARF Version 5.</i> 2944 29451. `DW_OP_piece` 2946 2947 `DW_OP_piece` has a single unsigned LEB128 integer that represents a byte 2948 size S. 2949 2950 The action is based on the context: 2951 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. 2954 2955 An incomplete composite location storage LS is created with a single part 2956 P. P specifies a location description PL and has a bit size of S scaled by 2957 8 (the byte size). PL is comprised of one undefined location description 2958 PSL. 2959 2960 SL specifies LS with a bit offset of 0. 2961 2962 - Otherwise, if the top stack entry is a location description L comprised of 2963 one incomplete composite location description SL, then the incomplete 2964 composite location storage LS that SL specifies is updated to append a new 2965 part P. P specifies a location description PL and has a bit size of S 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 2969 converted to one, then it is popped and treated as a part location 2970 description PL. Then: 2971 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 2974 incomplete composite location storage LS that SL specifies is updated to 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. 2977 - Otherwise, a location description L comprised of one 2978 incomplete composite location description SL is pushed on 2979 the stack. 2980 2981 An incomplete composite location storage LS is created with a single 2982 part P. P specifies the location description PL and has a bit size of S 2983 scaled by 8 (the byte size). 2984 2985 SL specifies LS with a bit offset of 0. 2986 2987 - Otherwise, the DWARF expression is ill-formed 2988 2989 <i>Many compilers store a single variable in sets of registers or store a 2990 variable partially in memory and partially in registers. `DW_OP_piece` 2991 provides a way of describing where a part of a variable is located.</i> 2992 2993 <i>The evaluation rules for the `DW_OP_piece` operation allow it to be 2994 compatible with the DWARF Version 5 definition.</i> 2995 2996 > NOTE: Since these extensions allow location descriptions to be entries on 2997 > the stack, a simpler operation to create composite location descriptions 2998 > could be defined. For example, just one operation that specifies how many 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 3001 > complexities of incomplete composite location descriptions, but it may 3002 > also have a smaller encoding in practice. However, the desire for 3003 > compatibility with DWARF Version 5 is likely a stronger consideration. 3004 30052. `DW_OP_bit_piece` 3006 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 3009 integer that represents a bit displacement B. 3010 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 3013 updated by a bit offset B. 3014 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 3017 description.</i> 3018 3019#### A.2.5.5 DWARF Location List Expressions 3020 3021> NOTE: This section replaces DWARF Version 5 section 2.6.2. 3022 3023<i>To meet the needs of recent computer architectures and optimization 3024techniques, debugging information must be able to describe the location of an 3025object whose location changes over the object's lifetime, and may reside at 3026multiple locations during parts of an object's lifetime. Location list 3027expressions are used in place of operation expressions whenever the object whose 3028location is being described has these requirements.</i> 3029 3030A location list expression consists of a series of location list entries. Each 3031location list entry is one of the following kinds: 3032 30331. <i>Bounded location description</i> 3034 3035 This kind of location list entry provides an operation expression that 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. 3041 3042 The location list entry matches when the current program location is within 3043 the given range. 3044 3045 There are several kinds of bounded location description entries which differ 3046 in the way that they specify the starting and ending addresses. 3047 30482. <i>Default location description</i> 3049 3050 This kind of location list entry provides an operation expression that 3051 evaluates to the location description of an object that is valid when no 3052 bounded location description entry applies. 3053 3054 The location list entry matches when the current program location is not 3055 within the range of any bounded location description entry. 3056 30573. <i>Base address</i> 3058 3059 This kind of location list entry provides an address to be used as the base 3060 address for beginning and ending address offsets given in certain kinds of 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 3066 3.1.1). 3067 3068 In the case of a compilation unit where all of the machine code is contained 3069 in a single contiguous section, no base address entry is needed. 3070 30714. <i>End-of-list</i> 3072 3073 This kind of location list entry marks the end of the location list 3074 expression. 3075 3076The address ranges defined by the bounded location description entries of a 3077location list expression may overlap. When they do, they describe a situation in 3078which an object exists simultaneously in more than one place. 3079 3080If all of the address ranges in a given location list expression do not 3081collectively cover the entire range over which the object in question is 3082defined, and there is no following default location description entry, it is 3083assumed that the object is not available for the portion of the range that is 3084not covered. 3085 3086The result of the evaluation of a DWARF location list expression is: 3087 3088- If the current program location is not specified, then it is an evaluation 3089 error. 3090 3091 > NOTE: If the location list only has a single default entry, should that be 3092 > considered a match if there is no program location? If there are non-default 3093 > entries then it seems it has to be an evaluation error when there is no 3094 > program location as that indicates the location depends on the program 3095 > location which is not known. 3096 3097- If there are no matching location list entries, then the result is a location 3098 description that comprises one undefined location description. 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 3103 evaluation of E. 3104 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 3107 matching location list entry. 3108 3109A location list expression can only be used as the value of a debugger 3110information entry attribute that is encoded using class `loclist` or 3111`loclistsptr` (see [7.5.5 Classes and Forms](#classes-and-forms)). The value of 3112the attribute provides an index into a separate object file section called 3113`.debug_loclists` or `.debug_loclists.dwo` (for split DWARF object files) that 3114contains the location list entries. 3115 3116A `DW_OP_call*` and `DW_OP_implicit_pointer` operation can be used to specify a 3117debugger information entry attribute that has a location list expression. 3118Several debugger information entry attributes allow DWARF expressions that are 3119evaluated with an initial stack that includes a location description that may 3120originate from the evaluation of a location list expression. 3121 3122<i>This location list representation, the `loclist` and `loclistsptr` class, and 3123the related `DW_AT_loclists_base` attribute are new in DWARF Version 5. Together 3124they eliminate most, or all of the code object relocations previously needed for 3125location list expressions.</i> 3126 3127> NOTE: The rest of this section is the same as DWARF Version 5 section 2.6.2. 3128 3129## A.3 Program Scope Entries 3130 3131> NOTE: This section provides changes to existing debugger information entry 3132> attributes. These would be incorporated into the corresponding DWARF Version 5 3133> chapter 3 sections. 3134 3135### A.3.3 Subroutine and Entry Point Entries 3136 3137#### A.3.3.5 Low-Level Information 3138 31391. A `DW_TAG_subprogram`, `DW_TAG_inlined_subroutine`, or `DW_TAG_entry_point` 3140 debugger information entry may have a `DW_AT_return_addr` attribute, whose 3141 value is a DWARF expression E. 3142 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 3145 compilation unit that contains E, an empty initial stack, and other context 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 3149 frame's subprogram or entry point is stored. 3150 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. 3153 3154 > NOTE: It is unclear why `DW_TAG_inlined_subroutine` has a 3155 > `DW_AT_return_addr` attribute but not a `DW_AT_frame_base` or 3156 > `DW_AT_static_link` attribute. Seems it would either have all of them or 3157 > none. Since inlined subprograms do not have a call frame it seems they 3158 > would have none of these attributes. 3159 31602. A `DW_TAG_subprogram` or `DW_TAG_entry_point` debugger information entry may 3161 have a `DW_AT_frame_base` attribute, whose value is a DWARF expression E. 3162 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 3165 compilation unit that contains E, an empty initial stack, and other context 3166 elements corresponding to the source language thread of execution upon which 3167 the user is focused, if any. 3168 3169 The DWARF is ill-formed if E contains a `DW_OP_fbreg` operation, or the 3170 resulting location description L is not comprised of one single location 3171 description SL. 3172 3173 If SL is a register location description for register R, then L is replaced 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 3176 default address space. 3177 3178 <i>This allows the more compact `DW_OP_reg*` to be used instead of 3179 `DW_OP_breg* 0`.</i> 3180 3181 > NOTE: This rule could be removed and require the producer to create the 3182 > required location description directly using `DW_OP_call_frame_cfa` or 3183 > `DW_OP_breg*`. This would also then allow a target to implement the call 3184 > frames within a large register. 3185 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. 3188 3189 The resulting L is the <i>frame base</i> for the subprogram or entry point. 3190 3191 <i>Typically, E will use the `DW_OP_call_frame_cfa` operation or be a stack 3192 pointer register plus or minus some offset.</i> 3193 31943. If a `DW_TAG_subprogram` or `DW_TAG_entry_point` debugger information entry 3195 is lexically nested, it may have a `DW_AT_static_link` attribute, whose 3196 value is a DWARF expression E. 3197 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 3200 compilation unit that contains E, an empty initial stack, and other context 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 3206 frame's subprogram or entry point. 3207 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. 3210 3211### A.3.4 Call Site Entries and Parameters 3212 3213#### A.3.4.2 Call Site Parameters 3214 32151. A `DW_TAG_call_site_parameter` debugger information entry may have a 3216 `DW_AT_call_value` attribute, whose value is a DWARF operation expression 3217 E<sub>1</sub>. 3218 3219 The result of the `DW_AT_call_value` attribute is obtained by evaluating 3220 E<sub>1</sub> with a context that has a result kind of a value, an unspecified 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. 3225 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 3228 `DW_TAG_call_site_parameter` debugger information entry may also have a 3229 `DW_AT_call_data_location` attribute whose value is a DWARF operation expression 3230 E<sub>2</sub>, and a `DW_AT_call_data_value` attribute whose value is a DWARF 3231 operation expression E<sub>3</sub>. 3232 3233 The value of the `DW_AT_call_data_location` attribute is obtained by evaluating 3234 E<sub>2</sub> with a context that has a result kind of a location description, 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 3241 be omitted. 3242 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. 3247 3248 The value of the `DW_AT_call_data_value` attribute is obtained by evaluating 3249 E<sub>3</sub> with a context that has a result kind of a value, an unspecified 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. 3254 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 3259 frame. 3260 3261 <i>The consumer may have to virtually unwind to the call site (see [6.4 Call 3262 Frame Information](#call-frame-information)) in order to evaluate these 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 3265 expression.</i> 3266 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 3270 not be provided. 3271 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 3276 Information](#call-frame-information)) will not be able to restore registers 3277 that have been clobbered, and clobbered memory will no longer have the value at 3278 the time of the call.</i> 3279 3280### A.3.5 Lexical Block Entries 3281 3282> NOTE: This section is the same as DWARF Version 5 section 3.5. 3283 3284## A.4 Data Object and Object List Entries 3285 3286> NOTE: This section provides changes to existing debugger information entry 3287> attributes. These would be incorporated into the corresponding DWARF Version 5 3288> chapter 4 sections. 3289 3290### A.4.1 Data Object Entries 3291 3292Program variables, formal parameters and constants are represented by debugging 3293information entries with the tags `DW_TAG_variable`, `DW_TAG_formal_parameter` 3294and `DW_TAG_constant`, respectively. 3295 3296*The tag `DW_TAG_constant` is used for languages that have true named constants.* 3297 3298The debugging information entry for a program variable, formal parameter or 3299constant may have the following attributes: 3300 33011. A `DW_AT_location` attribute, whose value is a DWARF expression E that 3302 describes the location of a variable or parameter at run-time. 3303 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 3306 compilation unit that contains E, an empty initial stack, and other context 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. 3310 3311 See [2.5.4.2 Control Flow Operations](#control-flow-operations) for special 3312 evaluation rules used by the `DW_OP_call*` operations. 3313 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. 3316 3317 > NOTE: See the discussion about the `DW_AT_location` attribute in the 3318 > `DW_OP_call*` operation. Having each attribute only have a single purpose 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. 3322 > 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 3327 > desirable. 3328 33292. `DW_AT_const_value` 3330 3331 > NOTE: Could deprecate using the `DW_AT_const_value` attribute for 3332 > `DW_TAG_variable` or `DW_TAG_formal_parameter` debugger information 3333 > entries that have been optimized to a constant. Instead, `DW_AT_location` 3334 > could be used with a DWARF expression that produces an implicit location 3335 > description now that any location description can be used within a DWARF 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 3338 > optimized. 3339 3340### A.4.2 Common Block Entries 3341 3342A common block entry also has a DW_AT_location attribute whose value is a DWARF 3343expression E that describes the location of the common block at run-time. The 3344result of the attribute is obtained by evaluating E with a context that has a 3345result kind of a location description, an unspecified object, the compilation 3346unit that contains E, an empty initial stack, and other context elements 3347corresponding to the source language thread of execution upon which the user is 3348focused, if any. The result of the evaluation is the location description of the 3349base of the common block. See 2.5.4.2 Control Flow Operations for special 3350evaluation rules used by the DW_OP_call* operations. 3351 3352## A.5 Type Entries 3353 3354> NOTE: This section provides changes to existing debugger information entry 3355> attributes. These would be incorporated into the corresponding DWARF Version 5 3356> chapter 5 sections. 3357 3358### A.5.7 Structure, Union, Class and Interface Type Entries 3359 3360#### A.5.7.3 Derived or Extended Structures, Classes and Interfaces 3361 33621. For a `DW_AT_data_member_location` attribute there are two cases: 3363 3364 1. If the attribute is an integer constant B, it provides the offset in 3365 bytes from the beginning of the containing entity. 3366 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. 3371 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 3374 byte.</i> 3375 3376 2. Otherwise, the attribute must be a DWARF expression E which is evaluated 3377 with a context that has a result kind of a location description, an 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. 3384 3385 > NOTE: The beginning of the containing entity can now be any location 3386 > description, including those with more than one single location 3387 > description, and those with single location descriptions that are of any 3388 > kind and have any bit offset. 3389 3390#### A.5.7.8 Member Function Entries 3391 33921. An entry for a virtual function also has a `DW_AT_vtable_elem_location` 3393 attribute whose value is a DWARF expression E. 3394 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 3402 enclosing class. 3403 3404### A.5.14 Pointer to Member Type Entries 3405 34061. The `DW_TAG_ptr_to_member_type` debugging information entry has a 3407 `DW_AT_use_location` attribute whose value is a DWARF expression E. It is used 3408 to compute the location description of the member of the class to which the 3409 pointer to member entry points. 3410 3411 <i>The method used to find the location description of a given member of a 3412 class, structure, or union is common to any instance of that class, structure, 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 3415 has a pointer to member type.</i> 3416 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 3419 and for a particular structure or class instance. 3420 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 3423 unit that contains E, an initial stack comprising two entries, and other context 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 3430 points. 3431 3432### A.5.18 Dynamic Properties of Types 3433 3434#### A.5.18.1 Data Location 3435 34361. The `DW_AT_data_location` attribute may be used with any type that provides one 3437 or more levels of hidden indirection and/or run-time parameters in its 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. 3442 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. 3449 3450 <i>E will typically involve an operation expression that begins with a 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 3453 calculation.</i> 3454 3455 > NOTE: Since `DW_AT_data_member_location`, `DW_AT_use_location`, and 3456 > `DW_AT_vtable_elem_location` allow both operation expressions and location 3457 > list expressions, why does `DW_AT_data_location` not allow both? In all cases 3458 > they apply to data objects so less likely that optimization would cause 3459 > different operation expressions for different program location ranges. But if 3460 > supporting for some then should be for all. 3461 > 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 3464 > expression has to need it. 3465 3466## A.6 Other Debugging Information 3467 3468> NOTE: This section provides changes to existing debugger information entry 3469> attributes. These would be incorporated into the corresponding DWARF Version 5 3470> chapter 6 sections. 3471 3472### A.6.2 Line Number Information 3473 3474> NOTE: This section is the same as DWARF Version 5 section 6.2. 3475 3476### A.6.4 Call Frame Information 3477 3478> NOTE: This section provides changes to DWARF Version 5 section 6.4. Register 3479> unwind DWARF expressions are generalized to allow any location description, 3480> including those with composite and implicit location descriptions. 3481 3482#### A.6.4.1 Structure of Call Frame Information 3483 3484The register rules are: 3485 34861. <i>undefined</i> 3487 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 3490 description (see [2.5.4.4.2 Undefined Location Description 3491 Operations](#undefined-location-description-operations)). 3492 3493 <i>By convention, the register is not preserved by a callee.</i> 3494 34952. <i>same value</i> 3496 3497 This register has not been modified from the previous caller frame. 3498 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. 3503 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. 3508 3509 <i>By convention, the register is preserved by the callee, but the callee 3510 has not modified it.</i> 3511 35123. <i>offset(N)</i> 3513 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 3516 current CFA (see [2.5.4 DWARF Operation 3517 Expressions](#dwarf-operation-expressions)) updated with the bit offset N 3518 scaled by 8 (the byte size). 3519 35204. <i>val_offset(N)</i> 3521 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). 3527 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. 3531 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 3537 space.</i> 3538 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. 3543 > 3544 > GDB has a per register hook that allows a target specific conversion on a 3545 > register by register basis. It defaults to truncation of bigger registers, 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 3548 > tests that read a register out of bounds (except an illegal hand written 3549 > assembly test). 3550 35515. <i>register(R)</i> 3552 3553 This register has been stored in another register numbered R. 3554 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 3557 location for register R. 3558 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 3561 information. 3562 3563 > NOTE: Should this also allow R to be larger than this register? If so is 3564 > the value stored in the low order bits and it is undefined what is stored 3565 > in the extra upper bits? 3566 35676. <i>expression(E)</i> 3568 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 3571 Operation Expressions](#dwarf-operation-expressions)). 3572 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 3576 current CFA (see [2.5.4 DWARF Operation 3577 Expressions](#dwarf-operation-expressions)). 3578 35797. <i>val_expression(E)</i> 3580 3581 The previous value of this register is located at the implicit location 3582 description created from the value produced by evaluating the DWARF 3583 operation expression E (see [2.5.4 DWARF Operation 3584 Expressions](#dwarf-operation-expressions)). 3585 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 3589 [2.5.4 DWARF Operation Expressions](#dwarf-operation-expressions)). 3590 3591 The DWARF is ill-formed if the resulting value type size does not match the 3592 register size. 3593 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 3596 > allowing any operations that specify a type in a CFI operation expression. 3597 > This makes it unusable for registers that are larger than the generic 3598 > type. However, <i>expression(E)</i> can be used to create an implicit 3599 > location description of any size. 3600 36018. <i>architectural</i> 3602 3603 The rule is defined externally to this specification by the augmenter. 3604 3605A Common Information Entry (CIE) holds information that is shared among many 3606Frame Description Entries (FDE). There is at least one CIE in every non-empty 3607`.debug_frame` section. A CIE contains the following fields, in order: 3608 36091. `length` (initial length) 3610 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. 3615 36162. `CIE_id` (4 or 8 bytes, see [7.4 32-Bit and 64-Bit DWARF Formats](#bit-and-64-bit-dwarf-formats)) 3617 3618 A constant that is used to distinguish CIEs from FDEs. 3619 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. 3622 36233. `version` (ubyte) 3624 3625 A version number. This number is specific to the call frame information and 3626 is independent of the DWARF version number. 3627 3628 The value of the CIE version number is 4. 3629 3630 > NOTE: Would this be increased to 5 to reflect the changes in these 3631 > extensions? 3632 36334. `augmentation` (sequence of UTF-8 characters) 3634 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: 3638 3639 - CIE: length, CIE_id, version, augmentation 3640 - FDE: length, CIE_pointer, initial_location, address_range 3641 3642 If there is no augmentation, this value is a zero byte. 3643 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 3646 is needed to virtually unwind a stack frame. For example, this might be 3647 information about dynamically allocated data which needs to be freed on exit 3648 from the routine.</i> 3649 3650 <i>Because the `.debug_frame` section is useful independently of any 3651 `.debug_info` section, the augmentation string always uses UTF-8 3652 encoding.</i> 3653 36545. `address_size` (ubyte) 3655 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 3658 address size here. 3659 36606. `segment_selector_size` (ubyte) 3661 3662 The size of a segment selector in this CIE and any FDEs that use it, in 3663 bytes. 3664 36657. `code_alignment_factor` (unsigned LEB128) 3666 3667 A constant that is factored out of all advance location instructions (see 3668 [6.4.2.1 Row Creation Instructions](#row-creation-instructions)). The 3669 resulting value is `(operand * code_alignment_factor)`. 3670 36718. `data_alignment_factor` (signed LEB128) 3672 3673 A constant that is factored out of certain offset instructions (see [6.4.2.2 3674 CFA Definition Instructions](#cfa-definition-instructions) and [6.4.2.3 3675 Register Rule Instructions](#register-rule-instructions)). The 3676 resulting value is `(operand * data_alignment_factor)`. 3677 36789. `return_address_register` (unsigned LEB128) 3679 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 3682 not correspond to an actual machine register. 3683 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. 3687 368810. `initial_instructions` (array of ubyte) 3689 3690 A sequence of rules that are interpreted to create the initial setting of 3691 each column in the table. 3692 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 3695 compilation system authoring body may specify an alternate default value for 3696 any or all columns. 3697 369811. `padding` (array of ubyte) 3699 3700 Enough `DW_CFA_nop` instructions to make the size of this entry match the 3701 length value above. 3702 3703An FDE contains the following fields, in order: 3704 37051. `length` (initial length) 3706 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. 3711 37122. `CIE_pointer` (4 or 8 bytes, see [7.4 32-Bit and 64-Bit DWARF Formats](#bit-and-64-bit-dwarf-formats)) 3713 3714 A constant offset into the `.debug_frame` section that denotes the CIE that 3715 is associated with this FDE. 3716 37173. `initial_location` (segment selector and target address) 3718 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. 3722 37234. `address_range` (target address) 3724 3725 The number of bytes of program instructions described by this entry. 3726 37275. `instructions` (array of ubyte) 3728 3729 A sequence of table defining instructions that are described in [6.4.2 Call 3730 Frame Instructions](#call-frame-instructions). 3731 37326. `padding` (array of ubyte) 3733 3734 Enough `DW_CFA_nop` instructions to make the size of this entry match the 3735 length value above. 3736 3737#### A.6.4.2 Call Frame Instructions 3738 3739Some call frame instructions have operands that are encoded as DWARF operation 3740expressions E (see [2.5.4 DWARF Operation 3741Expressions](#dwarf-operation-expressions)). The DWARF operations that can be 3742used in E have the following restrictions: 3743 3744- `DW_OP_addrx`, `DW_OP_call2`, `DW_OP_call4`, `DW_OP_call_ref`, 3745 `DW_OP_const_type`, `DW_OP_constx`, `DW_OP_convert`, `DW_OP_deref_type`, 3746 `DW_OP_fbreg`, `DW_OP_implicit_pointer`, `DW_OP_regval_type`, 3747 `DW_OP_reinterpret`, and `DW_OP_xderef_type` operations are not allowed 3748 because the call frame information must not depend on other debug sections. 3749- `DW_OP_push_object_address` is not allowed because there is no object context 3750 to provide a value to push. 3751- `DW_OP_call_frame_cfa` and `DW_OP_entry_value` are not allowed because their 3752 use would be circular. 3753 3754<i>Call frame instructions to which these restrictions apply include 3755`DW_CFA_def_cfa_expression`, `DW_CFA_expression`, and 3756`DW_CFA_val_expression`.</i> 3757 3758##### A.6.4.2.1 Row Creation Instructions 3759 3760> NOTE: These instructions are the same as in DWARF Version 5 section 6.4.2.1. 3761 3762##### A.6.4.2.2 CFA Definition Instructions 3763 37641. `DW_CFA_def_cfa` 3765 3766 The `DW_CFA_def_cfa` instruction takes two unsigned LEB128 operands 3767 representing a register number R and a (non-factored) byte displacement B. 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` 3770 as a location description. 3771 37722. `DW_CFA_def_cfa_sf` 3773 3774 The `DW_CFA_def_cfa_sf` instruction takes two operands: an unsigned LEB128 3775 value representing a register number R and a signed LEB128 factored byte 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 3778 `DW_OP_bregx R, B * data_alignment_factor` as a location description. 3779 3780 <i>The action is the same as `DW_CFA_def_cfa`, except that the second 3781 operand is signed and factored.</i> 3782 37833. `DW_CFA_def_cfa_register` 3784 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 3789 old CFA byte displacement. 3790 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. 3793 37944. `DW_CFA_def_cfa_offset` 3795 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. 3801 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. 3804 38055. `DW_CFA_def_cfa_offset_sf` 3806 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 3810 DWARF operation expression `DW_OP_bregx R, B * data_alignment_factor` as a 3811 location description. R is the old CFA register number. 3812 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. 3815 3816 <i>The action is the same as `DW_CFA_def_cfa_offset`, except that the 3817 operand is signed and factored.</i> 3818 38196. `DW_CFA_def_cfa_expression` 3820 3821 The `DW_CFA_def_cfa_expression` instruction takes a single operand encoded 3822 as a `DW_FORM_exprloc` value representing a DWARF operation expression E. 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 3826 is unspecified, and an empty initial stack. 3827 3828 <i>See [6.4.2 Call Frame Instructions](#call-frame-instructions) regarding 3829 restrictions on the DWARF expression operations that can be used in E.</i> 3830 3831 The DWARF is ill-formed if the result of evaluating E is not a memory byte 3832 address location description. 3833 3834##### A.6.4.2.3 Register Rule Instructions 3835 38361. `DW_CFA_undefined` 3837 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`. 3841 38422. `DW_CFA_same_value` 3843 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`. 3847 38483. `DW_CFA_offset` 3849 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 3853 register specified by R to be an <i>offset(B * data_alignment_factor)</i> 3854 rule. 3855 3856 > NOTE: Seems this should be named `DW_CFA_offset_uf` since the offset is 3857 > unsigned factored. 3858 38594. `DW_CFA_offset_extended` 3860 3861 The `DW_CFA_offset_extended` instruction takes two unsigned LEB128 operands 3862 representing a register number R and a factored displacement B. This 3863 instruction is identical to `DW_CFA_offset`, except for the encoding and 3864 size of the register operand. 3865 3866 > NOTE: Seems this should be named `DW_CFA_offset_extended_uf` since the 3867 > displacement is unsigned factored. 3868 38695. `DW_CFA_offset_extended_sf` 3870 3871 The `DW_CFA_offset_extended_sf` instruction takes two operands: an unsigned 3872 LEB128 value representing a register number R and a signed LEB128 factored 3873 displacement B. This instruction is identical to `DW_CFA_offset_extended`, 3874 except that B is signed. 3875 38766. `DW_CFA_val_offset` 3877 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 3881 <i>val_offset(B * data_alignment_factor)</i> rule. 3882 3883 > NOTE: Seems this should be named `DW_CFA_val_offset_uf` since the 3884 displacement is unsigned factored. 3885 38867. `DW_CFA_val_offset_sf` 3887 3888 The `DW_CFA_val_offset_sf` instruction takes two operands: an unsigned 3889 LEB128 value representing a register number R and a signed LEB128 factored 3890 displacement B. This instruction is identical to `DW_CFA_val_offset`, except 3891 that B is signed. 3892 38938. `DW_CFA_register` 3894 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> 3898 rule. 3899 39009. `DW_CFA_expression` 3901 3902 The `DW_CFA_expression` instruction takes two operands: an unsigned LEB128 3903 value representing a register number R, and a `DW_FORM_block` value 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 3906 <i>expression(E)</i> rule. 3907 3908 <i>That is, E computes the location description where the register value can 3909 be retrieved.</i> 3910 3911 <i>See [6.4.2 Call Frame Instructions](#call-frame-instructions) regarding 3912 restrictions on the DWARF expression operations that can be used in E.</i> 3913 391410. `DW_CFA_val_expression` 3915 3916 The `DW_CFA_val_expression` instruction takes two operands: an unsigned 3917 LEB128 value representing a register number R, and a `DW_FORM_block` value 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 3920 <i>val_expression(E)</i> rule. 3921 3922 <i>That is, E computes the value of register R.</i> 3923 3924 <i>See [6.4.2 Call Frame Instructions](#call-frame-instructions) regarding 3925 restrictions on the DWARF expression operations that can be used in E.</i> 3926 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. 3929 393011. `DW_CFA_restore` 3931 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. 3936 393712. `DW_CFA_restore_extended` 3938 3939 The `DW_CFA_restore_extended` instruction takes a single unsigned LEB128 3940 operand that represents a register number R. This instruction is identical 3941 to `DW_CFA_restore`, except for the encoding and size of the register 3942 operand. 3943 3944##### A.6.4.2.4 Row State Instructions 3945 3946> NOTE: These instructions are the same as in DWARF Version 5 section 6.4.2.4. 3947 3948##### A.6.4.2.5 Padding Instruction 3949 3950> NOTE: These instructions are the same as in DWARF Version 5 section 6.4.2.5. 3951 3952#### A.6.4.3 Call Frame Instruction Usage 3953 3954> NOTE: The same as in DWARF Version 5 section 6.4.3. 3955 3956#### A.6.4.4 Call Frame Calling Address 3957 3958> NOTE: The same as in DWARF Version 5 section 6.4.4. 3959 3960## A.7 Data Representation 3961 3962> NOTE: This section provides changes to existing debugger information entry 3963> attributes. These would be incorporated into the corresponding DWARF Version 5 3964> chapter 7 sections. 3965 3966### A.7.4 32-Bit and 64-Bit DWARF Formats 3967 3968> NOTE: This augments DWARF Version 5 section 7.4 list item 3's table. 3969 3970 Form Role 3971 ------------------------ -------------------------------------- 3972 DW_OP_implicit_pointer offset in `.debug_info` 3973 3974### A.7.5 Format of Debugging Information 3975 3976#### A.7.5.5 Classes and Forms 3977 3978> NOTE: The same as in DWARF Version 5 section 7.5.5. 3979 3980### A.7.7 DWARF Expressions 3981 3982> NOTE: Rename DWARF Version 5 section 7.7 to reflect the unification of 3983> location descriptions into DWARF expressions. 3984 3985#### A.7.7.1 Operation Expressions 3986 3987> NOTE: Rename DWARF Version 5 section 7.7.1 and delete section 7.7.2 to reflect 3988> the unification of location descriptions into DWARF expressions. 3989 3990#### A.7.7.3 Location List Expressions 3991 3992> NOTE: Rename DWARF Version 5 section 7.7.3 to reflect that location lists are 3993> a kind of DWARF expression. 3994 3995# B. Further Information 3996 3997The following references provide additional information on the extension. 3998 3999A reference to the DWARF standard is provided. 4000 4001A formatted version of this extension is available on the LLVM site. It includes 4002many figures that help illustrate the textual description, especially of the 4003example DWARF expression evaluations. 4004 4005Slides and a video of a presentation at the Linux Plumbers Conference 2021 4006related to this extension are available. 4007 4008The LLVM compiler extension includes the operations mentioned in the motivating 4009examples. It also covers other extensions needed for heterogeneous devices. 4010 4011- [DWARF Debugging Information Format](https://dwarfstd.org/) 4012 - [DWARF Debugging Information Format Version 5](https://dwarfstd.org/Dwarf5Std.php) 4013- [Allow Location Descriptions on the DWARF Expression Stack](https://llvm.org/docs/AMDGPUDwarfExtensionAllowLocationDescriptionOnTheDwarfExpressionStack/AMDGPUDwarfExtensionAllowLocationDescriptionOnTheDwarfExpressionStack.html) 4014- DWARF extensions for optimized SIMT/SIMD (GPU) debugging - Linux Plumbers Conference 2021 4015 - [Video](https://www.youtube.com/watch?v=QiR0ra0ymEY&t=10015s) 4016 - [Slides](https://linuxplumbersconf.org/event/11/contributions/1012/attachments/798/1505/DWARF_Extensions_for_Optimized_SIMT-SIMD_GPU_Debugging-LPC2021.pdf) 4017- [DWARF Extensions For Heterogeneous Debugging](https://llvm.org/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.html) 4018
