1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 588 589 590 591 592 593 594 595 596 597 598 599 600 601 602 603 604 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 743 744 745 746 747 748 749 750 751 752 753 754 755 756 757 758 759 760 761 762 763 764 765 766 767 768 769 770 771 772 773 774 775 776 777 778 779 780 781 782 783 784 785 786 787 788 789 790 791 792 793 794 795 796 797 798 799 800 801 802 803 804 805 806 807 808 809 810 811 812 813 814 815 816 817 818 819 820 821 822 823 824 825 826 827 828 829 830 831 832 833 834 835 836 837 838 839 840 841 842 843 844 845 846 847 848 849 850 851 852 853 854 855 856 857 858 859 860 861 862 863 864 865 866 867 868 869 870 871 872 873 874 875 876 877 878 879 880 881 882 883 884 885 886 887 888 889 890 891 892 893 894 895 896 897 898 899 900 901 902 903 904 905 906 907 908 909 910 911 912 913 914 915 916 917 918 919 920 921 922 923 924 925 926 927 928 929 930 931 932 933 934 935 936 937 938 939 940 941 942 943 944 945 946 947 948 949 950 951 952 953 954 955 956 957 958 959 960 961 962 963 964 965 966 967 968 969 970 971 972 973 974 975 976 977 978 979 980 981 982 983 984 985 986 987 988 989 990 991 992 993 994 995 996 997 998 999 1000 1001 1002 1003 1004 1005 1006 1007 1008 1009 1010 1011 1012 1013 1014 1015 1016 1017 1018 1019 1020 1021 1022 1023 1024 1025 1026 1027 1028 1029 1030 1031 1032 1033 1034 1035 1036 1037 1038 1039 1040 1041 1042 1043 1044 1045 1046 1047 1048 1049 1050 1051 1052 1053 1054 1055 1056 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066 1067 1068 1069 1070 1071 1072 1073 1074 1075 1076 1077 1078 1079 1080 1081 1082 1083 1084 1085 1086 1087 1088 1089 1090 1091 1092 1093 1094 1095 1096 1097 1098 1099 1100 1101 1102 1103 1104 1105 1106 1107 1108 1109 1110 1111 1112 1113 1114 1115 1116 1117 1118 1119 1120 1121 1122 1123 1124 1125 1126 1127 1128 1129 1130 1131 1132 1133 1134 1135 1136 1137 1138 1139 1140 1141 1142 1143 1144 1145 1146 1147 1148 1149 1150 1151 1152 1153 1154 1155 1156 1157 1158 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178 1179 1180 1181 1182 1183 1184 1185 1186 1187 1188 1189 1190 1191 1192 1193 1194 1195 1196 1197 1198 1199 1200 1201 1202 1203 1204 1205 1206 1207 1208 1209 1210 1211 1212 1213 1214 1215 1216 1217 1218 1219 1220 1221 1222 1223 1224 1225 1226 1227 1228 1229 1230 1231 1232 1233 1234 1235 1236 1237 1238 1239 1240 1241 1242 1243 1244 1245 1246 1247 1248 1249 1250 1251 1252 1253 1254 1255 1256 1257 1258 1259 1260 1261 1262 1263 1264 1265 1266 1267 1268 1269 1270 1271 1272 1273 1274 1275 1276 1277 1278 1279 1280 1281 1282 1283 1284 1285 1286 1287 1288 1289 1290 1291 1292 1293 1294 1295 1296 1297 1298 1299 1300 1301 1302 1303 1304 1305 1306 1307 1308 1309 1310 1311 1312 1313 1314 1315 1316 1317 1318 1319 1320 1321 1322 1323 1324 1325 1326 1327 1328 1329 1330 1331 1332 1333 1334 1335 1336 1337 1338 1339 1340 1341 1342 1343 1344 1345 1346 1347 1348 1349 1350 1351 1352 1353 1354 1355 1356 1357 1358 1359 1360 1361 1362 1363 1364 1365 1366 1367 1368 1369 1370 1371 1372 1373 1374 1375 1376 1377 1378 1379 1380 1381 1382 1383 1384 1385 1386 1387 1388 1389 1390 1391 1392 1393 1394 1395 1396 1397 1398 1399 1400 1401 1402 1403 1404 1405 1406 1407 1408 1409 1410 1411 1412 1413 1414 1415 1416 1417 1418 1419 1420 1421 1422 1423 1424 1425 1426 1427 1428 1429 1430 1431 1432 1433 1434 1435 1436 1437 1438 1439 1440 1441 1442 1443 1444 1445 1446 1447 1448 1449 1450 1451 1452 1453 1454 1455 1456 1457 1458 1459 1460 1461 1462 1463 1464 1465 1466 1467 1468 1469 1470 1471 1472 1473 1474 1475 1476 1477 1478 1479 1480 1481 1482 1483 1484 1485 1486 1487 1488 1489 1490 1491 1492 1493 1494 1495 1496 1497 1498 1499 1500 1501 1502 1503 1504 1505 1506 1507 1508 1509 1510 1511 1512 1513 1514 1515 1516 1517 1518 1519 1520 1521 1522 1523 1524 1525 1526 1527 1528 1529 1530 1531 1532 1533 1534 1535 1536 1537 1538 1539 1540 1541 1542 1543 1544 1545 1546 1547 1548 1549 1550 1551 1552 1553 1554 1555 1556 1557 1558 1559 1560 1561 1562 1563 1564 1565 1566 1567 1568 1569 1570 1571 1572 1573 1574 1575 1576 1577 1578 1579 1580 1581 1582 1583 1584 1585 1586 1587 1588 1589 1590 1591 1592 1593 1594 1595 1596 1597 1598 1599 1600 1601 1602 1603 1604 1605 1606 1607 1608 1609 1610 1611 1612 1613 1614 1615 1616 1617 1618 1619 1620 1621 1622 1623 1624 1625 1626 1627 1628 1629 1630 1631 1632 1633 1634 1635 1636 1637 1638 1639 1640 1641 1642 1643 1644 1645 1646 1647 1648 1649 1650 1651 1652 1653 1654 1655 1656 1657 1658 1659 1660 1661 1662 1663 1664 1665 1666 1667 1668 1669 1670 1671 1672 1673 1674 1675 1676 1677 1678 1679 1680 1681 1682 1683 1684 1685 1686 1687 1688 1689 1690 1691 1692 1693 1694 1695 1696 1697 1698 1699 1700 1701 1702 1703 1704 1705 1706 1707 1708 1709 1710 1711 1712 1713 1714 1715 1716 1717 1718 1719 1720 1721 1722 1723 1724 1725 1726 1727 1728 1729 1730 1731 1732 1733 1734 1735 1736 1737 1738 1739 1740 1741 1742 1743 1744 1745 1746 1747 1748 1749 1750 1751 1752 1753 1754 1755 1756 1757 1758 1759 1760 1761 1762 1763 1764 1765 1766 1767 1768 1769 1770 1771 1772 1773 1774 1775 1776 1777 1778 1779 1780 1781 1782 1783 1784 1785 1786 1787 1788 1789 1790 1791 1792 1793 1794 1795 1796 1797 1798 1799 1800 1801 1802 1803 1804 1805 1806 1807 1808 1809 1810 1811 1812 1813 1814 1815 1816 1817 1818 1819 1820 1821 1822 1823 1824 1825 1826 1827 1828 1829 1830 1831 1832 1833 1834 1835 1836 1837 1838 1839 1840 1841 1842 1843 1844 1845 1846 1847 1848 | <!DOCTYPE html> <html> <head> <meta charset="utf-8" /> <meta name="viewport" content="width=device-width, initial-scale=1.0" /> <title>DWARF Spec Diffs for Locations on Stack Proposal</title> <link rel="stylesheet" href="../static/dwarf.css" type="text/css" /> </head> <body> <div class="contentwrapper"> <div class="content"> <h1>Chapter 2: General Description</h1> <h2><del>2.5 DWARF Expressions [Now Chapter 3]</del></h2> <h2><del>2.6 Location Descriptions [Now Chapter 3]</del></h2> <h2><ins>2.5 Values and Locations [NEW]</ins></h2> <p><ins>As described in Section 2.2, DWARF attributes may have different classes of values. In many cases, attribute values directly provide the numeric value of a property such as bounds of an array, the size of a type, the value of a named constant in the program, or a string value such as the name of a variable or type. In other cases, they provide the <em>location</em> of a data object, such as the address of a variable or common block (see Section 4.1), instead of directly providing the value of the object.</ins></p> <p><ins>The attribute value classes <em>constant</em> and <em>string</em> are used to provide static values for properties, but often the values need to be computed dynamically. The classes <em>exprval</em> and <em>vallist</em> indicate that the attribute value is to be computed by evaluating a DWARF expression (described in Chapter 3).</ins></p> <p><ins>A DWARF expression of class <em>exprval</em> can be used to compute a value that cannot be given statically, such as the upper bound of a dynamic array.</ins></p> <p><ins>Sometimes, an attribute value may depend on the program counter, such as the loop vectorization factor. A value list (see Section 3.18), encoded using class <em>vallist</em>, can be used in this case. A value list is a list of DWARF expressions, each associated with a range of program counters.</ins></p> <p><ins>The class <em>address</em> is used to provide a static memory address for an object located in memory, and the classes <em>exprloc</em> and <em>loclist</em> indicate that the location of an object is to be computed by evaluating a DWARF expression. In these cases, where the DWARF expression is expected to produce a location, the expression is called a “location expression.”</ins></p> <p><ins><em>(In DWARF 5, the term “location description” was used to refer both to a sequence of DWARF operations that evaluates to a location, and to the result of that evaluation. For DWARF 6, we use the terms “location expression” for the expression and “location” for the result of evaluating the expression.)</em></ins></p> <p><ins>The class <em>exprloc</em> is used to provide a location expression that yields a single location. This is sufficient to describe the location of an object whose lifetime is either static or the same as the lexical block that owns it (excluding any prologue or epilogue ranges), and that does not move during its lifetime.</ins></p> <p><ins>A location list (see Section 3.19), encoded using class <em>loclist</em>, describes objects that have a limited lifetime or that change their location during their lifetime. A location list is a list of location expressions, each associated with a range of program counters.</ins></p> <p><ins>A location list may have overlapping PC ranges, and thus may yield multiple locations at a given PC. In this case, the consumer may assume that the object value stored is the same in all locations, excluding bits of the object that serve as padding. Non-padding bits that are undefined (for example, as a result of optimization) must be undefined in all the locations.</ins></p> <p><ins><em>A location list that yields multiple locations can be used to describe objects that reside in more than one piece of storage at the same time. An object may have more than one location as a result of optimization. For example, a value that is only read may be promoted from memory to a register for some region of code, but later code may revert to reading the value from memory as the register may be used for other purposes.</em></ins></p> <p><ins>DWARF can describe the location of program objects in several kinds of storage, such as a memory address space or a register. Each kind of storage is treated as a linear stream of bits of finite size, organized into bytes and/or words. The ordering of bits uses the bit numbering and direction conventions that are appropriate to the target architecture and the ABI. <em>For example, on a little-endian architecture, bits are numbered within bytes and words from least-significant to most-significant (right-to-left), while on a big-endian architecture, bits are numbered left-to-right.</em></ins></p> <p><ins>A location names a block of storage and a (non-negative, zero-based) bit offset relative to the start of that storage. It gives the location of the program object, which occupies a sequence of contiguous bits starting at that location. The bit offset of a location must be less than the size of the named block of storage (for a zero-length block of storage, the offset must be 0).</ins></p> <p><ins>DWARF can describe locations in six kinds of storage:</ins></p> <ul> <li> <p><ins>Memory. Corresponds to the target architecture memory address spaces. There is always a default address space, and the target architecture may define additional address spaces. Each memory storage block is the size of the corresponding address space. <em>(The offset can be thought of as a byte or word address combined with a bit offset within the byte or word.)</em></ins></p> </li> <li> <p><ins>Registers. Corresponds to the target architecture registers. Each register storage block is the size of the corresponding register.</ins></p> </li> <li> <p><ins>Undefined storage. Indicates no value is available, as when a variable has been optimized out. The location names a block of imaginary storage that cannot be read. Writing to undefined storage has no effect. The size of an undefined storage block is the same as that of the largest memory address space or register.</ins></p> </li> <li> <p><ins>Implicit storage. Corresponds to fixed values that can only be read, as when a variable has been optimized out but can nevertheless be rematerialized from program context. The location names a block of imaginary storage, whose size is the same as the fixed value that it holds.</ins></p> </li> <li> <p><ins>Implicit pointer storage. A special form of implicit storage, created by the <code>DW_OP_implicit_pointer</code> operator (see Section 3.11). The location names a block of imaginary storage that holds a secondary location. Its size is the size of the pointer that was optimized away, but no physical pointer is available.</ins></p> </li> <li> <p><ins>Composite storage. A hybrid form of storage where different pieces of a program object map to different locations, as when a field of a structure or a slice of an array is promoted to a register while the rest remains in memory. Composite storage consists of a (possibly empty) series of contiguous pieces, and its size is the sum of the sizes of the pieces. The maximum size of a block of composite storage is the size of the largest address space or register.</ins></p> </li> </ul> <p>…</p> <hr /> <h1>Chapter 3: DWARF Expressions</h1> <p>DWARF expressions describe how to compute a value or specify a location. They are expressed in terms of DWARF operations that operate on a stack of <del>values</del> <ins>elements, each of which may be either a value or a location.</ins></p> <p>A DWARF expression is encoded as a stream of operations, each consisting of an opcode followed by zero or more literal operands. The number of operands is implied by the opcode.</p> <p><del>In addition to the general operations that are defined here, operations that are specific to location descriptions are defined in Section {locationdescriptions}.</del></p> <p><ins>The result of a DWARF expression is the value or location on the top of the stack after evaluating the operations.</ins></p> <p><ins>Values on the stack are typed, and can represent a value of any supported base type of the target machine, or of the generic type, which is an integral type that has the size of an address in the default address space on the target machine, and unspecified signedness.</ins></p> <p><del><em>The generic type is the same as the unspecified type used for stack operations defined in DWARF Version 4 and before.</em></del></p> <p><ins>An implicit conversion between a location and a value may happen during the execution of any operation or when evaluation of the expression is completed. If a location is expected, but the result is a value of integral type, the value is implicitly treated as a memory address in the default address space, and converted to a memory location. If a value is expected, and the result is an addressable memory location (i.e., if the offset is a multiple of the byte or word size) in the default address space, the address is implicitly converted to a value of the generic type.</ins></p> <p><del><em>Debugging information must provide consumers a way to find the location of program variables, determine the bounds of dynamic arrays and strings, and possibly to find the base address of a subroutine’s stack frame or the return address of a subroutine. Furthermore, to meet the needs of recent computer architectures and optimization techniques, debugging information must be able to describe the location of an object whose location changes over the object’s lifetime.</em></del></p> <h2><del>2.5.1</del> 3.1 DWARF Expression Evaluation Context</h2> <p>DWARF expressions <del>and location descriptions (see Section {locationdescriptions})</del> are evaluated within a context provided by the debugger or other DWARF consumer. The context includes the following elements:</p> <ol> <li> <p>Required result kind</p> <p>The kind of result required – either a location or a value – is determined by the DWARF construct where the expression is found.</p> <p><em>For example, DWARF attributes with <code>exprval</code> class require a value, and attributes with <del><code>locdesc</code></del> <ins><code>exprloc</code></ins> class require a location <del>description</del> (see Section {classesandforms}).</em></p> </li> <li> <p>Initial stack</p> <p>In most cases, the DWARF expression stack is empty at the start of expression evaluation. In certain circumstances, however, one or more <del>values</del> <ins>entries</ins> are pushed implicitly onto the stack before evaluation of the expression starts (e.g., <code>DW_AT_data_member_location</code>).</p> </li> <li> <p>Current compilation unit</p> <p>The current compilation unit is the compilation unit debugging information entry that contains the DWARF expression being evaluated.</p> <p>A current compilation unit is required for operations that reference debug information associated with the same compilation unit, including indicating if such references use the 32-bit or 64-bit DWARF format.</p> <p><em>For example, the <code>DW_OP_constx</code> and <code>DW_OP_addrx</code> operations require the address size, which is a property of the compilation unit.</em></p> <p><em>Note that this compilation unit might not be the same as the compilation unit determined from the loaded code object corresponding to the current program location. For example, the evaluation of the expression E associated with a <code>DW_AT_location</code> attribute of the debug information entry operand of the <code>DW_OP_call<n></code> operations is evaluated with the compilation unit that contains E and not the one that contains the <code>DW_OP_call<n></code> operation expression.</em></p> </li> <li> <p>Target architecture</p> <p>The target architecture is typically provided by the object file containing the DWARF information. It may also be refined by instruction set identifiers in the line number table.</p> <p>The target architecture is required for operations that specify architecture-specific entities.</p> <p><em>Architecture-specific entities include DWARF register identifiers, DWARF address space identifiers, the default address space, and the address space address sizes.</em></p> </li> <li> <p>Current thread</p> <p><em>Many programming environments support the concept of independent threads of execution, where the process and its address space are shared among the threads, but each thread has its own stack, program counter, and possibly its own block of memory for thread-local storage (TLS). These threads may be implemented in user-space or with kernel threads, or by a combination of the two.</em></p> <p>The current thread identifies a current thread of execution. When debugging a multi-threaded program, the current thread may be selected by a user command that focuses on a specific thread, or it may be selected automatically when the running thread stops at a breakpoint.</p> <p><em>If there is no current process (or an image of a process, as from a core file), there is no current thread.</em></p> <p>A current thread is required for the <del><code>DW_OP_form_tls_address</code></del> <ins><code>DW_OP_form_tls_location</code></ins> operation (see Section {stackoperations}) which provides access to thread-local storage.</p> </li> <li> <p>Current call frame</p> <p>The current call frame identifies an active invocation of a subprogram. It is identified by its address on the call stack (see Section {framebase}). The address is referred to as the frame base or the call frame address (CFA). The call frame information is used to determine the base addresses for the call frames of the current thread’s call stack (see Section {callframeinformation}).</p> <p><em>When debugging a running program or examining a core file, the current frame may be the topmost (most recently activated) frame (e.g., where a breakpoint has triggered), or may be selected by a user command to focus the view on a frame further down the call stack. The current frame provides a view of the state of the running process at a particular point in time.</em></p> <p>The current call frame (if there is one) must be an active call frame in the current call stack.</p> <p>A current call frame is required for operations that use the contents of registers (e.g., <code>DW_OP_reg<n></code>) or frame-local storage (e.g., <code>DW_OP_fbreg</code>) so that the debugger can retrieve values from the selected view of the process state.</p> </li> <li> <p>Current lane</p> <p><em>On SIMD (Single-Instruction Multiple-Data Stream) and SIMT (Single-Instruction Multiple-Thread) architectures, fine-grained parallel execution can be achieved by dispatching a single instruction across multiple data streams (e.g., a vector or array). Some parallel programming models allow for the vectorization of loops using SIMD instructions. These parallel streams can be considered fine-grain threads of execution, or lanes, where all lanes typically share a common stack, program counter, and register file.</em></p> <p><em>In SIMT architectures, control flow may diverge through the use of predication, where each instruction executes only in certain lanes. Some SIMT architectures, however, provide separate stacks and register files for each lane, and the parallel streams of execution may instead be represented as threads (above).</em></p> <p>The current lane is a SIMD/SIMT lane identifier. This applies to source languages with scalar code that is vectorized by the compiler using a SIMD/SIMT execution model. These implementations map vectorized operations to SIMD/SIMT lanes of execution (see Section {lanesinsimdvectorization}). When debugging a SIMD/SIMT program, the current lane is typically selected by a user command that focuses on a specific lane.</p> <p>The current lane number must be consistent with the value of the <code>DW_AT_num_lanes</code> attribute of the subprogram corresponding to the current frame and program location. It is consistent if the lane number is greater than or equal to 0 and less than the, possibly default, value of the <code>DW_AT_num_lanes</code> attribute.</p> <p>If the current program is not using a SIMD/SIMT execution model, the current lane is always 0.</p> <p>A current lane is required for the <code>DW_OP_push_lane</code> operation (see Section {stackoperations}), which pushes the value of the current lane.</p> </li> <li> <p>Current program counter (PC)</p> <p>The current program counter (PC) identifies the current point of execution in the current call frame.</p> <p>The PC in each call frame is the address of the next instruction to be executed in that frame. For the top (most recent) frame on the call stack, this is where execution would resume; for frames lower on the stack, it is where the callee will return. The call frame information is used to obtain the value of the return address register to determine the PC of the other call frames (see Section {callframeinformation}).</p> <p>If there is no current frame, there is no current PC.</p> <p>The current PC is used during the evaluation of value lists and location lists to select from among multiple program location ranges.</p> <p><em>When evaluating value lists and location lists when no current PC is available, only default <del>location descriptions</del> <ins>value or location list entries</ins> may be used.</em></p> </li> <li> <p>Current object</p> <p>The current object is a data object described by a data object entry (see Section {dataobjectentries}) that is being inspected. When evaluating expressions that provide attribute values of a data object, the containing debugging information entry is the current object. When evaluating expressions that provide attribute values for a type (e.g., <code>DW_AT_data_location</code> for a <code>DW_TAG_member</code>), the current object is the data object entry (if there is one) that referred to the type entry (e.g., via <code>DW_AT_type</code>).</p> <p>A current object is required for the <del><code>DW_OP_push_object_address</code></del> <ins><code>DW_OP_push_object_location</code></ins> (see Section {stackoperations}) operation and <ins>is implicitly defined</ins> by some attributes (e.g., <code>DW_AT_data_member_location</code> and <code>DW_AT_use_location</code>) where the object’s location is provided as part of the initial stack.</p> </li> </ol> <p><em>A DWARF expression <del>for a location description</del> may be able to be evaluated without a thread, call frame, lane, program counter, or architecture context element. For example, the location of a global variable may be able to be evaluated without such context, while the location of local variables in a stack frame cannot be evaluated without additional context.</em></p> <h2><del>2.5.2 General Operations [REMOVED]</del></h2> <p><del>Each general operation represents a postfix operation on a simple stack machine. Each element of the stack has a type and a value, and can represent a value of any supported base type of the target machine. Instead of a base type, elements can have a generic type, which is an integral type that has the size of an address on the target machine and unspecified signedness. The value on the top of the stack after “executing” the DWARF expression is taken to be the result (the address of the object, the value of the array bound, the length of a dynamic string, the desired value itself, and so on).</del></p> <p><del><em>The generic type is the same as the unspecified type used for stack operations defined in DWARF Version 4 and before.</em></del></p> <h2><del>2.5.2.3</del> 3.2 Stack Operations</h2> <p>The following operations manipulate the DWARF stack, <ins>and may operate on both values and locations.</ins> Operations that index the stack assume that the top of the stack (most recently added entry) has index 0.</p> <p>Each entry on the stack <del>has an associated type</del> <ins>is either a value (with an associated type) or a location</ins>.</p> <ol> <li> <p><code>DW_OP_dup</code><br /> The <code>DW_OP_dup</code> operation duplicates the <del>value (including its type identifier)</del> <ins>entry</ins> at the top of the stack.</p> </li> <li> <p><code>DW_OP_drop</code><br /> The <code>DW_OP_drop</code> operation pops the <del>value (including its type identifier)</del> <ins>entry</ins> at the top of the stack.</p> </li> <li> <p><code>DW_OP_pick</code><br /> The single operand of the <code>DW_OP_pick</code> operation provides a 1-byte index. A copy of the stack entry <del>(including its type identifier)</del> with the specified index (0 through 255, inclusive) is pushed onto the stack.</p> </li> <li> <p><code>DW_OP_over</code><br /> The <code>DW_OP_over</code> operation duplicates the entry currently second in the stack at the top of the stack. This is equivalent to a <code>DW_OP_pick</code> operation, with index 1.</p> </li> <li> <p><code>DW_OP_swap</code><br /> The <code>DW_OP_swap</code> operation swaps the top two stack entries. The entry at the top of the stack <del>(including its type identifier)</del> becomes the second stack entry, and the second entry <del>(including its type identifier)</del> becomes the top of the stack.</p> </li> <li> <p><code>DW_OP_rot</code><br /> The <code>DW_OP_rot</code> operation rotates the first three stack entries. The entry at the top of the stack <del>(including its type identifier)</del> becomes the third stack entry, the second entry <del>(including its type identifier)</del> becomes the top of the stack, and the third entry <del>(including its type identifier)</del> becomes the second entry.</p> </li> </ol> <p><em>Examples illustrating many of these stack operations are found in Appendix {dwarfstackoperationexamples}.</em></p> <h2><del>2.5.2.1</del> 3.3 Literal <del>Encodings</del> <ins>and Constant Operations</ins></h2> <p>The following operations all push a value onto the DWARF stack. Operations other than <code>DW_OP_const_type</code> push a value with the generic type, and if the value of a constant in one of these operations is larger than can be stored in a single stack element, the value is truncated to the element size and the low-order bits are pushed on the stack.</p> <ol> <li> <p><code>DW_OP_lit0</code>, <code>DW_OP_lit1</code>, …, <code>DW_OP_lit31</code><br /> The <code>DW_OP_lit<n></code> operations encode the unsigned literal values from 0 through 31, inclusive.</p> </li> <li> <p><code>DW_OP_const1u</code>, <code>DW_OP_const2u</code>, <code>DW_OP_const4u</code>, <code>DW_OP_const8u</code><br /> The single operand of a <code>DW_OP_const<n>u</code> operation provides a 1, 2, 4, or 8-byte unsigned integer constant, respectively.</p> </li> <li> <p><code>DW_OP_const1s</code>, <code>DW_OP_const2s</code>, <code>DW_OP_const4s</code>, <code>DW_OP_const8s</code><br /> The single operand of a <code>DW_OP_const<n>s</code> operation provides a 1, 2, 4, or 8-byte signed integer constant, respectively.</p> </li> <li> <p><code>DW_OP_constu</code><br /> The single operand of the <code>DW_OP_constu</code> operation provides an unsigned LEB128 integer constant.</p> </li> <li> <p><code>DW_OP_consts</code><br /> The single operand of the <code>DW_OP_consts</code> operation provides a signed LEB128 integer constant.</p> </li> <li> <p><code>DW_OP_constx</code><br /> The <code>DW_OP_constx</code> operation has a single operand that encodes an unsigned LEB128 value, which is a zero-based index into the <code>.debug_addr</code> section, where a constant, the size of <del>a machine address</del> <ins>the generic type</ins>, is stored. This index is relative to the value of the <code>DW_AT_addr_base</code> attribute of the associated compilation unit.</p> <p><em>The <code>DW_OP_constx</code> operation is provided for constants that require link-time relocation but should not be interpreted by the consumer as a relocatable address (for example, offsets to thread-local storage).</em></p> </li> <li> <p><code>DW_OP_const_type</code><br /> The <code>DW_OP_const_type</code> operation takes three operands. The first operand is an unsigned LEB128 integer that represents the offset of a debugging information entry in the current compilation unit, which must be a <code>DW_TAG_base_type</code> entry that provides the type of the constant provided. The second operand is a 1-byte unsigned integer that specifies the size of the constant value, which is the same as the size of the base type referenced by the first operand. The third operand is a sequence of bytes of the given size that is interpreted as a value of the referenced type.</p> <p><em>While the size of the constant can be inferred from the base type definition, it is encoded explicitly into the operation so that the operation can be parsed easily without reference to the <code>.debug_info</code> section.</em></p> </li> </ol> <h2><del>2.5.2.2</del> 3.4 Register Value Operations</h2> <p>The following operations push <del>a value onto the stack that is either part or all of</del> the contents of a register <del>or the result of adding the contents of a register to a given signed offset</del> <ins>onto the stack</ins>. <del><code>DW_OP_regval_type</code> pushes the contents of a register together with the given base type. <code>DW_OP_regval_bits</code> pushes the partial contents of a register together with the generic type. The other operations push the result of adding the contents of a register to a given signed offset together with the generic type.</del></p> <ol> <li> <p><code>DW_OP_regval_type</code><br /> The <code>DW_OP_regval_type</code> operation pushes the contents of a given register interpreted as a value of a given type. The first operand is an unsigned LEB128 number, which identifies a register whose contents is to be pushed onto the stack. The second operand is an unsigned LEB128 number that represents the offset of a debugging information entry in the current compilation unit, which must be a <code>DW_TAG_base_type</code> entry that provides the type of the value contained in the specified register.</p> </li> <li> <p><code>DW_OP_regval_bits</code><br /> The <code>DW_OP_regval_bits</code> operation takes a single unsigned LEB128 integer operand, which gives the number of bits to read. This number must be smaller or equal to the bit size of the generic type. It pops the top two stack elements and interprets the top element as an unsigned bit offset from the least significant bit end and the other as a register number identifying the register from which to extract the value. If the extracted value is smaller than the size of the generic type, it is zero extended.</p> </li> </ol> <h2><del>2.5.2.4</del> 3.5 Arithmetic and Logical Operations</h2> <p>The following provide arithmetic and logical operations. <ins>The operations in this section take one or two stack operands, which must be values.</ins> Operands of an operation with two operands must have the same type, either the same base type or the generic type. The result of the operation which is pushed back has the same type as the type of the operand(s).</p> <p><del>If the type of the operands is the generic type, except as otherwise specified, the arithmetic operations perform addressing arithmetic, that is, unsigned arithmetic that is performed modulo one plus the largest representable address.</del></p> <p>Operations other than <code>DW_OP_abs</code>, <code>DW_OP_div</code>, <code>DW_OP_minus</code>, <code>DW_OP_mul</code>, <code>DW_OP_neg</code> and <code>DW_OP_plus</code> require integral types of the operand (either integral base type or the generic type). Operations do not cause an exception on overflow.</p> <ol> <li> <p><code>DW_OP_abs</code><br /> The <code>DW_OP_abs</code> operation pops the top stack entry, interprets it as a signed value and pushes its absolute value. If the absolute value cannot be represented, the result is undefined.</p> </li> <li> <p><code>DW_OP_and</code><br /> The <code>DW_OP_and</code> operation pops the top two stack values, performs a bitwise and operation on the two, and pushes the result.</p> </li> <li> <p><code>DW_OP_div</code><br /> The <code>DW_OP_div</code> operation pops the top two stack values, divides the former second entry by the former top of the stack using signed division, and pushes the result.</p> </li> <li> <p><code>DW_OP_minus</code><br /> The <code>DW_OP_minus</code> operation pops the top two stack values, subtracts the former top of the stack from the former second entry, and pushes the result.</p> </li> <li> <p><code>DW_OP_mod</code><br /> The <code>DW_OP_mod</code> operation pops the top two stack values and pushes the result of the calculation: former second stack entry modulo the former top of the stack.</p> </li> <li> <p><code>DW_OP_mul</code><br /> The <code>DW_OP_mul</code> operation pops the top two stack entries, multiplies them together, and pushes the result.</p> </li> <li> <p><code>DW_OP_neg</code><br /> The <code>DW_OP_neg</code> operation pops the top stack entry, interprets it as a signed value and pushes its negation. If the negation cannot be represented, the result is undefined.</p> </li> <li> <p><code>DW_OP_not</code><br /> The <code>DW_OP_not</code> operation pops the top stack entry, and pushes its bitwise complement.</p> </li> <li> <p><code>DW_OP_or</code><br /> The <code>DW_OP_or</code> operation pops the top two stack entries, performs a bitwise or operation on the two, and pushes the result.</p> </li> <li> <p><code>DW_OP_plus</code><br /> The <code>DW_OP_plus</code> operation pops the top two stack entries, adds them together, and pushes the result.</p> </li> <li> <p><code>DW_OP_plusuconst</code><br /> The <code>DW_OP_plusuconst</code> operation pops the top stack entry, adds it to the unsigned LEB128constant operand interpreted as the same type as the operand popped from the top of the stack and pushes the result.</p> <p><em>This operation is supplied specifically to be able to encode more field offsets in two bytes than can be done with “<code>DW_OP_lit<n> DW_OP_plus</code>”.</em></p> </li> <li> <p><code>DW_OP_shl</code><br /> The <code>DW_OP_shl</code> operation pops the top two stack entries, shifts the former second entry left (filling with zero bits) by the number of bits specified by the former top of the stack, and pushes the result.</p> </li> <li> <p><code>DW_OP_shr</code><br /> The <code>DW_OP_shr</code> operation pops the top two stack entries, shifts the former second entry right logically (filling with zero bits) by the number of bits specified by the former top of the stack, and pushes the result.</p> </li> <li> <p><code>DW_OP_shra</code><br /> The <code>DW_OP_shra</code> operation pops the top two stack entries, shifts the former second entry right arithmetically (divide the magnitude by 2, keep the same sign for the result) by the number of bits specified by the former top of the stack, and pushes the result.</p> </li> <li> <p><code>DW_OP_xor</code><br /> The <code>DW_OP_xor</code> operation pops the top two stack entries, performs a bitwise exclusive-or operation on the two, and pushes the result.</p> </li> </ol> <h2><ins>3.6 Context Query Operations</ins></h2> <p><ins>The following operations can be used to push a value or location obtained from the expression evaluation context (see Section 3.1) onto the stack:</ins></p> <ol> <li> <p><del><code>DW_OP_push_object_address</code></del> <ins><code>DW_OP_push_object_location</code></ins><br /> <del>The <code>DW_OP_push_object_address</code> operation pushes the address of the object currently being evaluated as part of evaluation of a user presented expression (see Section {dwarfexpressionevaluationcontext}). This object may correspond to an independent variable described by its own debugging information entry or it may be a component of an array, structure, or class whose address has been dynamically determined by an earlier step during user expression evaluation.</del></p> <p><ins>The <code>DW_OP_push_object_location</code> operation pushes the location of the current object (see Section 3.1) onto the stack, as part of evaluation of a user presented expression.</ins></p> <p><ins><em>This object may correspond to an independent variable described by its own debugging information entry; or it may be a component of an array, structure, or class whose address has been dynamically determined by an earlier step during user expression evaluation.</em></ins></p> <p><em>This operator provides explicit functionality (especially for arrays involving descriptors) that is analogous to the implicit push of the base address of a structure prior to evaluation of a <code>DW_AT_data_member_location</code> to access a data member of a structure. For an example, see Appendix D.2.</em></p> <p><ins><em>In previous versions of DWARF, this operator was named <code>DW_OP_push_object_address</code>. The old name is still supported in DWARF 6 for compatibility.</em></ins></p> </li> <li> <p><del><code>DW_OP_form_tls_address</code></del> <ins><code>DW_OP_form_tls_location</code></ins><br /> The <del><code>DW_OP_form_tls_address</code></del> <ins><code>DW_OP_form_tls_location</code></ins> operation pops a value from the stack, which must have an integral type <del>identifier</del>, translates this value into <del>an address</del> <ins>a location</ins> in the thread-local storage for the current thread (see Section 3.1), and pushes the <del>address</del> <ins>location</ins> onto the stack <del>together with the generic type identifier</del>. The meaning of the value on the top of the stack prior to this operation is defined by the run-time environment. If the run-time environment supports multiple thread-local storage blocks for a single thread, then the block corresponding to the executable or shared library containing this DWARF expression is used.</p> <p><em>Some implementations of C, C++, Fortran, and other languages, support a thread-local storage class. Variables with this storage class have distinct values and addresses in distinct threads, much as automatic variables have distinct values and addresses in each function invocation. Typically, there is a single block of storage containing all thread-local variables declared in the main executable, and a separate block for the variables declared in each shared library. Each thread-local variable can then be accessed in its block using an identifier. This identifier is typically an offset into the block and pushed onto the DWARF stack by one of the <code>DW_OP_const<n><x></code> operations prior to the <del><code>DW_OP_form_tls_address</code></del> <ins><code>DW_OP_form_tls_location</code></ins> operation. Computing the address of the appropriate block can be complex (in some cases, the compiler emits a function call to do it), and difficult to describe using ordinary DWARF location <del>descriptions</del> <ins>expressions</ins>. Instead of forcing complex thread-local storage calculations into the DWARF expressions, the <del><code>DW_OP_form_tls_address</code></del> <ins><code>DW_OP_form_tls_location</code> operation</ins> allows the consumer to perform the computation based on the run-time environment.</em></p> <p><ins><em>In previous versions of DWARF, this operator was named <code>DW_OP_form_tls_address</code>. The old name is still supported in DWARF 6 for compatibility.</em></ins></p> </li> <li> <p><code>DW_OP_call_frame_cfa</code><br /> The <code>DW_OP_call_frame_cfa</code> operation pushes the value of the current call frame address (CFA), obtained from the Call Frame Information (see Section {dwarfexpressionevaluationcontext} and Section {callframeinformation}).</p> <p><em>Although the value of <code>DW_AT_frame_base</code> can be computed using other DWARF expression operators, in some cases this would require an extensive location list because the values of the registers used in computing the CFA change during a subroutine. If the Call Frame Information is present, then it already encodes such changes, and it is space efficient to reference that.</em></p> </li> <li> <p><code>DW_OP_push_lane</code><br /> The <code>DW_OP_push_lane</code> operation pushes a lane index value of the generic type, which provides the context of the lane in which the expression is being evaluated (see Section {dwarfexpressionevaluationcontext} and Section {lowlevelinformation}).</p> </li> </ol> <h2><del>2.6.1.1.2</del> 3.7 Memory Locations</h2> <p><ins>A memory location represents the location of a piece or all of an object or other entity in memory. On architectures that support multiple address spaces, a memory location identifies storage associated with the address space.</ins></p> <p><ins>In contexts that expect a location, a value of the generic type will be implicitly converted to a memory location in the default address space.</ins></p> <p><ins>The following operations push memory locations onto the stack:</ins></p> <ol> <li> <p><code>DW_OP_addr</code><br /> The <code>DW_OP_addr</code> operation has a single operand that encodes a machine address and whose size is the size of an address on the target machine. <ins>The value of this operand is treated as an address in the default address space and the corresponding memory location is pushed onto the stack.</ins></p> </li> <li> <p><code>DW_OP_addrx</code><br /> The <code>DW_OP_addrx</code> operation has a single operand that encodes an unsigned LEB128 value, which is a zero-based index into the <code>.debug_addr</code> section, where a machine address is stored. This index is relative to the value of the <code>DW_AT_addr_base</code> attribute of the associated compilation unit. <ins>The address obtained is treated as an address in the default address space and the corresponding memory location is pushed onto the stack.</ins></p> </li> <li> <p><code>DW_OP_fbreg</code><br /> The <code>DW_OP_fbreg</code> operation provides a signed LEB128 <ins>byte</ins> offset <ins><code>B</code></ins> from the <del>address</del> <ins>location</ins> specified by the location <del>description</del> <ins>expression</ins> in the <code>DW_AT_frame_base</code> attribute of the current function (see Section 3.1). <ins>The frame base location, offset by <code>B</code> bytes, is pushed onto the stack.</ins></p> <p><em>This is typically a stack pointer register plus or minus some offset.</em></p> </li> <li> <p><code>DW_OP_breg0</code>, <code>DW_OP_breg1</code>, …, <code>DW_OP_breg31</code><br /> The single operand of the <code>DW_OP_breg<n></code> operations provides a signed LEB128 <del>offset from the contents of the specified register</del> <ins>byte offset. The contents of the specified register (0–31) are treated as a memory address in the default address space. The offset is added to the address obtained from the register and the resulting memory location is pushed onto the stack.</ins></p> </li> <li> <p><code>DW_OP_bregx</code><br /> <del>The <code>DW_OP_bregx</code> operation provides the sum of two values specified by its two operands. The first operand is a register number which is specified by an unsigned LEB128number. The second operand is a signed LEB128 offset.</del><br /> <ins>The <code>DW_OP_bregx</code> operation has two operands. The first operand is a register number which is specified by an unsigned LEB128 number. The second operand is a signed LEB128 byte offset. It is the same as <code>DW_OP_breg<n></code> except it uses the register and offset provided by the operands.</ins></p> </li> </ol> <h2><del>2.6.1.1.3</del> 3.8 Register Locations</h2> <p><del>A register location description consists of a register name operation, which represents a piece or all of an object located in a given register.</del></p> <p><em>Register location descriptions describe an object (or a piece of an object) that resides in a register, while the opcodes listed in Section {registervalues} are used to describe an object (or a piece of an object) that is located in memory at an address that is contained in a register (possibly offset by some constant). <del>A register location description must stand alone as the entire description of an object or a piece of an object.</del></em></p> <p>The following DWARF operations can be used to specify a register location.</p> <p><em>Note that the register number represents a DWARF specific mapping of numbers onto the actual registers of a given architecture. The mapping should be chosen to gain optimal density and should be shared by all users of a given architecture. It is recommended that this mapping be defined by the ABI authoring committee for each architecture.</em></p> <ol> <li> <p><code>DW_OP_reg0</code>, <code>DW_OP_reg1</code>, …, <code>DW_OP_reg31</code><br /> The <code>DW_OP_reg<n></code> operations encode the names of up to 32 registers, numbered from 0 through 31, inclusive. <del>The object addressed is in register <em>n</em>.</del> <ins>A location that names the storage associated with the designated register, with an offset of 0, is formed and pushed on the stack.</ins></p> </li> <li> <p><code>DW_OP_regx</code><br /> The <code>DW_OP_regx</code> operation has a single unsigned LEB128 literal operand that encodes the name of a register. <ins>A location that names the storage associated with the designated register, with an offset of 0, is formed and pushed on the stack.</ins></p> </li> </ol> <p><em>These operations name a register <del>location</del>, <ins>not the contents of the register</ins>. To fetch the contents of a register, it is necessary to use one of the register based addressing operations, such as <code>DW_OP_bregx</code> (Section 3.7), <ins>the register value operation <code>DW_OP_regval_type</code> (Section 3.4), or a <code>DW_OP_reg</code> operation followed by a derefencing operation (Section 3.13)</ins>.</em></p> <h2><del>2.6.1.1.1</del> 3.9 Undefined Locations</h2> <p><del>An empty location description consists of a DWARF expression containing no operations. It represents a piece or all of an object that is present in the source but not in the object code (perhaps due to optimization).</del></p> <p><ins>An undefined location represents a piece or all of an object that is present in the source but not in the object code (perhaps due to optimization). An undefined location cannot be read. Writing to undefined storage has no effect.</ins></p> <ol> <li> <p><ins><code>DW_OP_undefined</code></ins><br /> <ins>The <code>DW_OP_undefined</code> operation pushes an undefined location with an offset of 0 onto the stack.</ins></p> </li> <li> <p><ins>A DWARF expression containing no operations or that leaves no elements on the stack also produces an undefined location. <em>This is for compatibility with earlier versions of DWARF.</em></ins></p> </li> </ol> <h2><del>2.6.1.1.4</del> 3.10 Implicit Locations</h2> <p><em>DWARF location <del>descriptions</del> <ins>expressions</ins> are intended to yield the <strong>location</strong> of a value rather than the value itself. An optimizing compiler may perform a number of code transformations where it becomes impossible to give a location for a value, but it remains possible to describe the value itself. Section 3.8 describes operators that can be used to describe the location of a value when that value exists in a register but not in memory. The operations in this section are used to describe values that exist neither in memory nor in a single register.</em></p> <p>An implicit location <del>description</del> represents a piece or all of an object which has no actual location but whose contents are nonetheless <del>either known or known to be undefined</del> <ins>known</ins>.</p> <p>The following DWARF operations may be used to specify a value that has no location in the program but is a known constant or is computed from other locations and values in the program.</p> <ol> <li> <p><code>DW_OP_implicit_value</code><br /> The <code>DW_OP_implicit_value</code> operation specifies an immediate value using two operands: an unsigned LEB128 length, followed by a sequence of bytes of the given length that contain the value. <ins>A location <code>L</code> is formed for a block of implicit storage which contains the given byte sequence. The offset of <code>L</code> is set to 0, and <code>L</code> is pushed onto the stack.</ins></p> </li> <li> <p><code>DW_OP_stack_value</code><br /> The <code>DW_OP_stack_value</code> operation specifies that the object does not exist in memory but its value is nonetheless known and is at the top of the DWARF expression stack. <del>In this form of location description, the DWARF expression represents the actual value of the object, rather than its location. The <code>DW_OP_stack_value</code> operation terminates the expression.</del> <ins>The value <code>V</code> on top of the stack is popped, and a location <code>L</code> is formed for a block of implicit storage containing the value <code>V</code>, represented using the encoding and byte order of the value’s type. The offset of <code>L</code> is set to 0 and <code>L</code> is pushed onto the stack.</ins></p> </li> </ol> <h2><ins>3.11 Implicit Pointer Locations [NEW]</ins></h2> <p><em>An optimizing compiler may eliminate a pointer, while still retaining the <del>value</del> <ins>object</ins> that the pointer addressed. <code>DW_OP_implicit_pointer</code> allows a producer to describe <del>this value</del> <ins>the location (or value) of the latter object</ins>.</em></p> <p><ins>An implicit pointer location is used to describe</ins> a pointer <ins>object <code>P</code></ins> that cannot be represented as a real pointer, even though the <ins>location or</ins> value <ins>of the object</ins> it would point to can be described. <del>In this form of location description, the DWARF expression</del> <ins>It</ins> refers to a debugging information entry that represents the <del>actual value of the</del> object <ins><code>V</code></ins> to which the pointer would point. Thus, a consumer of the debug information would be able to show the value of the dereferenced pointer, even when it cannot show the value of the pointer itself.</p> <p>The following DWARF operation is used to create an implicit pointer location:</p> <ol> <li> <p><code>DW_OP_implicit_pointer</code></p> <p><del>The <code>DW_OP_implicit_pointer</code> operation has two operands: a reference to a debugging information entry that describes the dereferenced object’s value, and a signed number that is treated as a byte offset from the start of that value. The first operand is a 4-byte unsigned value in the 32-bit DWARF format, or an 8-byte unsigned value in the 64-bit DWARF format (see Section {32bitand64bitdwarfformats}) that is used as the offset of a debugging information entry in the <code>.debug_info</code> section of the current executable or shared object file. The second operand is a signed LEB128 number.</del></p> <p><em><del>The debugging information entry referenced by a <code>DW_OP_implicit_pointer</code> operation is typically a <code>DW_TAG_variable</code> or <code>DW_TAG_formal_parameter</code> entry whose <code>DW_AT_location</code> attribute gives a second DWARF expression or a location list that describes the value of the object, but the referenced entry may be any entry that contains a <code>DW_AT_location</code> or <code>DW_AT_const_value</code> attribute (for example, <code>DW_TAG_dwarf_procedure</code>). By using the second DWARF expression, a consumer can reconstruct the value of the object when asked to dereference the pointer described by the original DWARF expression containing the <code>DW_OP_implicit_pointer</code> operation.</del></em></p> <p><ins>The <code>DW_OP_implicit_pointer</code> operation has two operands. The first operand is a reference to a debugging information entry <code>D</code>. It is a 4-byte unsigned value in the 32-bit DWARF format, or an 8-byte unsigned value in the 64-bit DWARF format (see Section {32bitand64bitdwarfformats}) that is used as the offset of the debugging information entry <code>D</code> in the <code>.debug_info</code> section of the current executable or shared object file. The second operand is a signed LEB128 number that is treated as a byte offset <code>B</code>.</ins></p> <p><ins>The debugging information entry <code>D</code> must contain a <code>DW_AT_location</code> attribute or a <code>DW_AT_const_value</code> attribute. In the first case, the <code>DW_AT_location</code> attribute is evaluated to obtain a location; in the second case, an implicit location is formed to hold the constant value. The byte offset <code>B</code> is added to that location and the resulting location is used as the location of the object <code>V</code>.</ins></p> <p><ins>A location <code>L</code> is formed for a block of implicit pointer storage, which describes the location of the pointer object <code>P</code>. The implicit pointer storage represents the location of the object <code>V</code>, and has the size of the pointer that was optimized away. The offset of <code>L</code> is set to 0, and <code>L</code> is pushed onto the stack.</ins></p> <p><em><ins>The debugging information entry <code>D</code> is typically a <code>DW_TAG_variable</code> or <code>DW_TAG_formal_parameter</code> entry whose <code>DW_AT_location</code> attribute evaluates to the location of the object <code>V</code>, but it may be any entry that contains a <code>DW_AT_location</code> or <code>DW_AT_const_value</code> attribute (for example, <code>DW_TAG_dwarf_procedure</code>). The location of <code>V</code> would typically be an implicit value, a register, or a composite location (an optimized-out pointer to a memory location could be described more simply as an implicit value).</ins></em></p> </li> </ol> <h2><del>2.6.1.2</del> 3.12 Composite Locations</h2> <p><del>A composite location description describes an object or value which may be contained in part of a register or stored in more than one location. Each piece is described by a composition operation, which does not compute a value nor store any result on the DWARF stack. There may be one or more composition operations in a single composite location description. A series of such operations describes the parts of a value in memory address order.</del></p> <p><del>Each composition operation is immediately preceded by a simple location description which describes the location where part of the resultant value is contained.</del></p> <p><ins>A composite location represents the location of an object or value that does not exist in a single block of contiguous storage <em>(e.g., as the result of compiler optimization where part of the object is promoted to a register)</em>. Its storage consists of a (possibly empty) sequence of pieces, where each piece maps a fixed range of bits from the object onto a corresponding range of bits at a new (sub-)location.</ins></p> <p><ins>The pieces of a block of composite storage are contiguous, so that the size of the composite storage is the sum of the sizes of the individual pieces, and each piece covers a range of bits immediately following the previous piece. The maximum size of a block of composite storage is the size of the largest address space or register.</ins></p> <p><em><ins>Typically, the size of a composite storage is the same as that of the object it describes. If the composite storage is smaller than the object, the remaining bits of the object are treated as undefined.</ins></em></p> <p><em><ins>In the process of fetching a value from a composite location, the consumer may need to fetch and assemble bits from more than one piece.</ins></em></p> <p><ins>The following operation is used to form a new, empty, composite location:</ins></p> <ol> <li> <p><ins><code>DW_OP_composite</code></ins><br /> <ins>The <code>DW_OP_composite</code> operator has no operands. It pushes a new, empty, composite location onto the stack, with an offset of 0.</ins></p> <p><ins><em>This operator is provided so that a new series of piece operations can be started to form a composite location when the state of the stack is unknown (e.g., following a <code>DW_OP_call*</code> operation), or when a new composite is to be started (e.g., rather than add to a previous composite location on the stack).</em></ins></p> </li> </ol> <p><ins>The following operations are used to build a composite location in storage order, one piece at a time. Each piece operation expects a sub-location, <code>L</code>, at the top of the stack, and the composite location under construction, <code>C</code>, in the preceding element on the stack. It pops those two locations and extends <code>C</code> by adding a new piece that maps the given number of bytes or bits to the sub-location <code>L</code>. The offset of the new location is the same as that of <code>C</code>. The new composite location is pushed onto the stack.</ins></p> <ol> <li> <p><code>DW_OP_piece</code><br /> The <code>DW_OP_piece</code> operation takes a single operand, which is an unsigned LEB128 number. The number describes the size, in bytes, of the piece of the object <del>referenced by the preceding simple location description</del> <ins>to be appended to the composite <code>C</code></ins>.</p> <p>If <del>the piece is located in a register,</del> <ins>the sub-location <code>L</code> is a register location,</ins> but <ins>the piece</ins> does not occupy the entire register, the placement of the piece within that register is defined by the ABI.</p> <p><del><em>Many compilers store a single variable in sets of registers, or store a variable partially in memory and partially in registers. <code>DW_OP_piece</code> provides a way of describing how large a part of a variable a particular DWARF location description refers to.</em></del></p> </li> <li> <p><code>DW_OP_bit_piece</code><br /> The <code>DW_OP_bit_piece</code> operation takes two operands. The first is an unsigned LEB128 number that gives the size, in bits, of the piece <ins>to be appended</ins>. The second is an unsigned LEB128 number that gives the offset in bits <del>from the location defined by the preceding DWARF location description</del> <ins>to be applied to the sub-location <code>L</code></ins>.</p> <p>Interpretation of the offset depends on the location <del>description</del>. If the location <del>description</del> is <del>empty</del> <ins>an undefined location</ins> (see Section {undefinedlocations}), the <code>DW_OP_bit_piece</code> operation describes a piece consisting of the given number of bits whose values are undefined, and the offset is ignored. If the location is a memory <del>address</del> <ins>location</ins> (see Section {memorylocationdescriptions}) <ins>or a composite location</ins>, the <code>DW_OP_bit_piece</code> operation describes a sequence of bits relative to the location <del>whose address is</del> on the top of the DWARF stack using the bit numbering and direction conventions that are appropriate to the current language on the target system. In all other cases, the source of the piece is given by either a register location (see Section {registerlocationdescriptions}) or an implicit value <del>description</del> <ins>location</ins> (see Section {implicitlocationdescriptions}); the offset is from the least significant bit of the source value.</p> <p><em><code>DW_OP_bit_piece</code> is used instead of <code>DW_OP_piece</code> when the piece to be assembled into a value or assigned to is not byte-sized or is not at the start of a register or addressable unit of memory.</em></p> <p><em>Whether or not a <code>DW_OP_piece</code> operation is equivalent to any <code>DW_OP_bit_piece</code> operation with an offset of 0 is ABI dependent.</em></p> </li> </ol> <p><del>A composition operation that follows an empty location description indicates that the piece is undefined, for example because it has been optimized away.</del></p> <p><ins>For compatibility with DWARF Version 5 and earlier, the following exceptions apply to the piece operations:</ins></p> <ul> <li> <p><ins>If <code>L</code> is a non-composite location (or convertible to one) and is the only element on the stack, the result is a new composite location with the single piece <code>L</code> (as if <code>DW_OP_composite DW_OP_swap</code> had been processed immediately prior to the piece operation). <em>This rule supports the first piece operation in a DWARF 5 expression.</em></ins></p> </li> <li> <p><ins>If a piece operation is processed while the stack is empty, a new empty composite and an undefined location are pushed implicitly (as if <code>DW_OP_composite DW_OP_undefined</code> had been processed immediately prior to the piece operation). The result is a composite with a single undefined piece. <em>This rule supports the empty piece operation in DWARF 5 when it is the first piece of a composite.</em></ins></p> </li> <li> <p><ins>If the top of the stack is a composite location, and is the only element on the stack, an undefined location is pushed implicitly (as if <code>DW_OP_undefined</code> had been processed immediately prior to the piece operation), whereupon the composite on top of the stack is taken as <code>C</code> and the undefined location is <code>L</code>. The result is the addition of an undefined piece to the existing composite location. <em>This rule supports the empty piece operation in DWARF 5 when it is not the first piece of a composite.</em></ins></p> </li> </ul> <h2><ins>3.13 Dereferencing Operations [NEW]</ins></h2> <p><ins>The following operations are used to dereference a location on the stack; i.e., to load a value (or another location) stored at that location. Each operation defines the number of bytes or bits to be loaded.</ins></p> <p><ins>Dereferencing a memory location simply loads a value from memory. Dereferencing a register location extracts all or some of the bits from the register, depending on the offset of the location and the size of value to be loaded. Dereferencing an implicit location loads a value (or, in the case of an implicit pointer, another location) from the implicit storage. Attempting to dereference an undefined location is an error.</ins></p> <p><ins>When dereferencing from a composite location, the value to be loaded may span more than one of the pieces of the composite, and the consumer must reassemble the value from the component pieces.</ins></p> <ol> <li> <p><code>DW_OP_deref</code><br /> <del>The <code>DW_OP_deref</code> operation pops the top stack entry and treats it as an address. The popped value must have an integral type. The value retrieved from that address is pushed, and has the generic type. The size of the data retrieved from the dereferenced address is the size of an address on the target machine.</del></p> <p><ins>The <code>DW_OP_deref</code> operation pops a location <code>L</code> from the top of the stack. The first <code>S</code> bits, where <code>S</code> is the size (in bits) of an address on the target machine, are retrieved from the location <code>L</code> and pushed onto the stack as a value of the generic type.</ins></p> <p><del>If the location on the stack is an implicit pointer (see Section 3.11), the location <code>LP</code> is dereferenced to obtain the location <code>LV</code>. In this case, the offset of the location <code>LP</code> must be 0.</del></p> </li> <li> <p><code>DW_OP_deref_size</code><br /> <del>The <code>DW_OP_deref_size</code> operation behaves like the <code>DW_OP_deref</code> operation: it pops the top stack entry and treats it as an address. The popped value must have an integral type. The value retrieved from that address is pushed, and has the generic type. In the <code>DW_OP_deref_size</code> operation, however, the size in bytes of the data retrieved from the dereferenced address is specified by the single operand. This operand is a 1-byte unsigned integral constant whose value may not be larger than the size of the generic type. The data retrieved is zero extended to the size of an address on the target machine before being pushed onto the expression stack.</del><br /> <ins>The <code>DW_OP_deref_size</code> takes a single 1-byte unsigned integral operand that specifies the size <code>S</code>, in bytes, of the value to be retrieved. The size <code>S</code> must be no larger than the size of the generic type. The operation behaves like the <code>DW_OP_deref</code> operation: it pops a location <code>L</code> from the stack. The first <code>S</code> bytes are retrieved from the location <code>L</code>, zero extended to the size of the generic type, and pushed onto the stack as a value of the generic type.</ins></p> </li> <li> <p><code>DW_OP_deref_type</code><br /> <del>The <code>DW_OP_deref_type</code> operation behaves like the <code>DW_OP_deref_size</code> operation: it pops the top stack entry and treats it as an address. The popped value must have an integral type. The value retrieved from that address is pushed together with a type identifier. In the <code>DW_OP_deref_type</code> operation, the size in bytes of the data retrieved from the dereferenced address is specified by the first operand. This operand is a 1-byte unsigned integral constant whose value which is the same as the size of the base type referenced by the second operand. The second operand is an unsigned LEB128 integer that represents the offset of a debugging information entry in the current compilation unit, which must be a <code>DW_TAG_base_type</code> entry that provides the type of the data pushed.</del><br /> <ins>The <code>DW_OP_deref_type</code> operation takes two operands. The first operand is a 1-byte unsigned integer that specifies the byte size <code>S</code> of the type given by the second operand. The second operand is an unsigned LEB128 integer that represents the offset of a debugging information entry in the current compilation unit, which must be a <code>DW_TAG_base_type</code> entry that provides the type <code>T</code> of the value to be retrieved. The size <code>S</code> must be the same as the byte size of the base type represented by the type <code>T</code>. This operation pops a location <code>L</code> from the stack. The first <code>S</code> bytes are retrieved from the location <code>L</code> and pushed onto the stack as a value of type <code>T</code>.</ins></p> <p><del><em>While the size of the pushed value could be inferred from the base type definition, it is encoded explicitly into the operation so that the operation can be parsed easily without reference to the <code>.debug_info</code> section.</em></del></p> </li> <li> <p><code>DW_OP_xderef</code><br /> The <code>DW_OP_xderef</code> operation provides an extended dereference mechanism. The entry at the top of the stack is treated as an address. The second stack entry is treated as an “address space identifier” for those architectures that support multiple address spaces. Both of these entries must have integral type<ins>s</ins> <del>identifiers</del>. The top two stack elements are popped, and a data item is retrieved through an implementation-defined address calculation and pushed as the new stack top together with the generic type <del>identifier</del>. The size of the data retrieved from the dereferenced address is the size of the generic type.</p> </li> <li> <p><code>DW_OP_xderef_size</code><br /> The <code>DW_OP_xderef_size</code> operation behaves like the <code>DW_OP_xderef</code> operation. The entry at the top of the stack is treated as an address. The second stack entry is treated as an “address space identifier” for those architectures that support multiple address spaces. Both of these entries must have integral type<ins>s</ins> <del>identifiers</del>. The top two stack elements are popped, and a data item is retrieved through an implementation-defined address calculation and pushed as the new stack top. In the <code>DW_OP_xderef_size</code> operation, however, the size in bytes of the data retrieved from the dereferenced address is specified by the single operand. This operand is a 1-byte unsigned integral constant whose value may not be larger than the size of an address on the target machine. The data retrieved is zero extended to the size of an address on the target machine before being pushed onto the expression stack together with the generic type <del>identifier</del>.</p> </li> <li> <p><code>DW_OP_xderef_type</code><br /> The <code>DW_OP_xderef_type</code> operation behaves like the <code>DW_OP_xderef_size</code> operation: it pops the top two stack entries, treats them as an address and an address space identifier, and pushes the value retrieved. In the <code>DW_OP_xderef_type</code> operation, the size in bytes of the data retrieved from the dereferenced address is specified by the first operand. This operand is a 1-byte unsigned integral constant whose value <del>value which</del> is the same as the size of the base type referenced by the second operand. The second operand is an unsigned LEB128 integer that represents the offset of a debugging information entry in the current compilation unit, which must be a <code>DW_TAG_base_type</code> entry that provides the type of the data pushed.</p> </li> </ol> <h2><ins>3.14 Offset Operations [NEW]</ins></h2> <p><ins>In addition to the composite operations, locations may be modified by the following operations:</ins></p> <ol> <li> <p><ins><code>DW_OP_offset</code></ins><br /> <ins><code>DW_OP_offset</code> pops two stack entries. The first (top of stack) must be an integral type value, which represents a signed byte displacement. The second must be a location. It forms an updated location by adding the given byte displacement to the offset component of the original location and pushes the updated location onto the stack.</ins></p> </li> <li> <p><ins><code>DW_OP_bit_offset</code></ins><br /> <ins><code>DW_OP_bit_offset</code> pops two stack entries. The first (top of stack) must be an integral type value, which represents a signed bit displacement. The second must be a location. It forms an updated location by adding the given bit displacement to the offset component of the original location and pushes the updated location onto the stack.</ins></p> <p><ins><em>A bit offset of <code>N × byte_size</code> is equivalent to a byte offset of <code>N</code>.</em></ins></p> </li> </ol> <p><ins>The resulting offset must remain valid for the location.</ins></p> <h2><del>2.5.2.5</del> 3.15 Control Flow Operations</h2> <p>The following operations provide simple control of the flow of a DWARF expression.</p> <ol> <li> <p><code>DW_OP_le</code>, <code>DW_OP_ge</code>, <code>DW_OP_eq</code>, <code>DW_OP_lt</code>, <code>DW_OP_gt</code>, <code>DW_OP_ne</code><br /> The six relational operators each:</p> <ul> <li> <p>pop the top two stack values, which have the same type, either the same base type or the generic type,</p> </li> <li> <p>compare the operands:<br /> <code><former second entry></code> <code><relational operator></code> <code><former top entry></code></p> </li> <li> <p>push the constant value 1 onto the stack if the result of the operation is true or the constant value 0 if the result of the operation is false. The pushed value has the generic type.</p> </li> </ul> <p>If the operands have the generic type, the comparisons are performed as signed operations.</p> </li> <li> <p><code>DW_OP_skip</code><br /> <code>DW_OP_skip</code> is an unconditional branch. Its single operand is a 2-byte signed integer constant. The 2-byte constant is the number of bytes of the DWARF expression to skip forward or backward from the current operation, beginning after the 2-byte constant.</p> </li> <li> <p><code>DW_OP_bra</code><br /> <code>DW_OP_bra</code> is a conditional branch. Its single operand is a 2-byte signed integer constant. This operation pops the top of stack. If the value popped is not <del>the constant</del> 0, the <del>2-byte</del> constant operand is the number of bytes of the DWARF expression to skip forward or backward from the current operation, beginning after the 2-byte constant.</p> </li> <li> <p><code>DW_OP_call2</code>, <code>DW_OP_call4</code>, <code>DW_OP_call_ref</code><br /> <code>DW_OP_call2</code>, <code>DW_OP_call4</code>, and <code>DW_OP_call_ref</code> perform DWARF procedure calls during evaluation of a DWARF expression or location description. For <code>DW_OP_call2</code> and <code>DW_OP_call4</code>, the operand is the 2- or 4-byte unsigned offset, respectively, of a debugging information entry in the current compilation unit. The <code>DW_OP_call_ref</code> operator has a single operand. In the 32-bit DWARF format, the operand is a 4-byte unsigned value; in the 64-bit DWARF format, it is an 8-byte unsigned value (see Section {32bitand64bitdwarfformats}). The operand is used as the offset of a debugging information entry in the <code>.debug_info</code> section of the current executable or shared object file.</p> <p><em>Operand interpretation of <code>DW_OP_call2</code>, <code>DW_OP_call4</code> and <code>DW_OP_call_ref</code> is exactly like that for <code>DW_FORM_ref2</code>, <code>DW_FORM_ref4</code> and <code>DW_FORM_ref_addr</code>, respectively (see Section {attributeencodings}).</em></p> <p>These operations transfer control of DWARF expression evaluation to the <code>DW_AT_location</code> attribute of the referenced debugging information entry. If there is no such attribute, then there is no effect. Execution of the DWARF expression of a <code>DW_AT_location</code> attribute may <del>add to and/or remove from values on</del> <ins>pop elements from the stack and/or push values or locations onto</ins> the stack. Execution returns to the point following the call when the end of the attribute is reached. Values <ins>and locations</ins> on the stack at the time of the call may be used as parameters by the called expression, and <del>values</del> <ins>elements (values or locations)</ins> left on the stack by the called expression may be used as return values by prior agreement between the calling and called expressions.</p> </li> </ol> <h2><del>2.5.2.6</del> 3.16 Type Conversions</h2> <p>The following operations provide for explicit type conversion. <ins>The operand on top of the stack must be a value.</ins></p> <ol> <li> <p><code>DW_OP_convert</code><br /> The <code>DW_OP_convert</code> operation pops the top stack entry, converts it to a different type, then pushes the result. It takes one operand, which is an unsigned LEB128 integer that represents the offset of a debugging information entry in the current compilation unit, or value 0 which represents the generic type. If the operand is non-zero, the referenced entry must be a <code>DW_TAG_base_type</code> entry that provides the type to which the value is converted.</p> </li> <li> <p><code>DW_OP_reinterpret</code><br /> The <code>DW_OP_reinterpret</code> operation pops the top stack entry, reinterprets the bits in its value as a value of a different type, then pushes the result. It takes one operand, which is an unsigned LEB128 integer that represents the offset of a debugging information entry in the current compilation unit, or value 0 which represents the generic type. If the operand is non-zero, the referenced entry must be a <code>DW_TAG_base_type</code> entry that provides the type to which the value is <del>converted</del> <ins>reinterpreted</ins>. The type of the operand and result type must have the same size in bits.</p> </li> </ol> <h2><del>2.5.2.7</del> 3.17 Special Operations</h2> <p>There are these special operations currently defined:</p> <ol> <li> <p><code>DW_OP_nop</code><br /> The <code>DW_OP_nop</code> operation is a place holder. It has no effect on the <del>location</del> stack or any of its <del>values</del> <ins>elements</ins>.</p> </li> <li> <p><code>DW_OP_entry_value</code><br /> The <code>DW_OP_entry_value</code> operation pushes the value that an expression would have had, or a register location would have held, upon entering the current subprogram. It has two operands: an unsigned LEB128 length, followed by a block containing a DWARF expression or a register location description (see Section {registerlocationdescriptions}). The length operand specifies the length in bytes of the block. If the block contains a DWARF expression, the DWARF expression is evaluated as if it had been evaluated upon entering the current subprogram. The DWARF expression assumes no values are present on the DWARF stack initially and results in exactly one value being pushed on the DWARF stack when completed. If the block contains a register location description, <code>DW_OP_entry_value</code> pushes the value that register held upon entering the current subprogram.</p> <p><del><code>DW_OP_push_object_address</code></del> <ins><code>DW_OP_push_object_location</code></ins> is not meaningful inside of this DWARF operation.</p> <p><em>The register location description provides a more compact form for the case where the value was in a register on entry to the subprogram.</em></p> <p><em>The values needed to evaluate <code>DW_OP_entry_value</code> could be obtained in several ways. The consumer could suspend execution on entry to the subprogram, record values needed by <code>DW_OP_entry_value</code> expressions within the subprogram, and then continue; when evaluating <code>DW_OP_entry_value</code>, the consumer would use these recorded values rather than the current values. Or, when evaluating <code>DW_OP_entry_value</code>, the consumer could virtually unwind using the Call Frame Information (see Section {callframeinformation}) to recover register values that might have been clobbered since the subprogram entry point.</em></p> </li> <li> <p><code>DW_OP_extended</code><br /> The <code>DW_OP_extended</code> opcode encodes an extension operation. It has at least one operand: a ULEB128 constant identifying the extension operation. The remaining operands are defined by the extension opcode, which are named using a prefix of <code>DW_OP_</code>. The extension opcode 0 is reserved.</p> </li> <li> <p><code>DW_OP_user_extended</code><br /> The <code>DW_OP_user_extended</code> opcode encodes a producer extension operation. It has at least one operand: a ULEB128 constant identifying a producer extension operation. The remaining operands are defined by the producer extension. The producer extension opcode 0 is reserved and cannot be used by any producer extension.</p> <p><em>The <code>DW_OP_user_extended</code> encoding space can be understood to supplement the space defined by <code>DW_OP_lo_user</code> and <code>DW_OP_hi_user</code> that is allocated by <del>the standard</del> <ins>this specification</ins> for the same purpose.</em></p> </li> </ol> <h2><del>2.5.2</del> 3.18 Value Lists</h2> <p>Value lists are used in place of DWARF expressions whenever the value of an object’s attribute can change during the lifetime of that object.</p> <p>Value lists are contained in a separate object file section, along with location lists (see {locationlists}).</p> <p>A value list is indicated by an attribute whose value is of class <code>vallist</code> (see Section {classesandforms}).</p> <p>A value list consists of a series of value list entries. The representation of a value list is the same as for a location list (see {locationlists}), except that bounded location description and default location description entries are understood to provide DWARF expressions that produce values rather than location descriptions.</p> <p><del><em>The DWARF expressions in value list entries, being expressions and not location descriptions, may not contain any of the DWARF operations described in Section {locationdescriptions}.</em></del></p> <p>The address ranges defined by the bounded expressions of a value list may overlap. When they do, the meaning is undefined if the overlapping expressions do not produce the same value.</p> <h2><del>2.6.2</del> 3.19 Location Lists</h2> <p>Location lists are used in place of location <del>descriptions</del> <ins>expressions</ins> whenever the object whose location is being described can change location during its lifetime. Location lists are contained in a separate object file section called <code>.debug_loclists</code> or <code>.debug_loclists.dwo</code> (for split DWARF object files).</p> <p>A location list is indicated by <del>a location or other</del> <ins>an</ins> attribute whose value is of class <code>loclist</code> (see Section {classesandforms}).</p> <p><del><em>This location list representation, the <code>loclist</code> class, and the related <code>DW_AT_loclists_base</code> attribute are new in DWARF Version 5. Together they eliminate most or all of the object language relocations previously needed for location lists.</em></del></p> <p>A location list consists of a series of location list entries. Each location list entry is one of the following kinds:</p> <ul> <li> <p>Bounded location description.</p> <p>This kind of entry provides a location description that specifies the location of an object that is valid over a lifetime bounded by a starting and ending address. The starting address is the lowest address of the address range over which the location is valid. The ending address is the address of the first location past the highest address of the address range. When the current PC is within the given range, the location description may be used to locate the specified object. The location description is valid even if the address range includes addresses within a prologue or epilogue range.</p> <p>There are several kinds of bounded location description entries which differ in the way that they specify the starting and ending addresses.</p> <p>The address ranges defined by the bounded location descriptions of a location list may overlap. When they do, they describe a situation in which an object exists simultaneously in more than one place. If all of the address ranges in a given location list do not collectively cover the entire range over which the object in question is defined, and there is no following default location description, it is assumed that the object is not available for the portion of the range that is not covered.</p> <p>In the case of a bounded location description where the range is defined by a starting address and either an ending address or a length, a starting address consisting of the reserved address value (see Section {reservedtargetaddress}) indicates a non-existent range, which is equivalent to omitting the description.</p> </li> <li> <p>Default location description. This kind of entry provides a location description that specifies the location of an object that is valid when no bounded location description applies. As with simple location descriptions, the lifetime of a default location excludes any prologue or epilogue ranges.</p> </li> <li> <p>Base address. This kind of entry provides an address to be used as the base address for beginning and ending address offsets given in certain kinds of bounded location description. The applicable base address of a bounded location description entry is the address specified by the closest preceding base address entry in the same location list. If there is no preceding base address entry, then the applicable base address defaults to the base address of the compilation unit (see Section {fullandpartialcompilationunitentries}).</p> <p>In the case of a compilation unit where all of the machine code is contained in a single contiguous section, no base address entry is needed.</p> <p>If the base address is the reserved target address, either explicitly or by default, then the range of any bounded location description defined relative to that base address is non-existent, which is equivalent to omitting the description.</p> </li> <li> <p>End-of-list. This kind of entry marks the end of the location list.</p> </li> </ul> <p>A location list consists of a sequence of zero or more bounded location description or base address entries, optionally followed by a default location entry, and terminated by an end-of-list entry.</p> <p>If there is no current PC (see Section {dwarfexpressionevaluationcontext}), only the default location list entry is used.</p> <p>Each location list entry begins with a single byte identifying the kind of that entry, followed by zero or more operands depending on the kind.</p> <p>In the descriptions that follow, these terms are used for operands:</p> <ul> <li> <p>A counted location description operand consists of an unsigned ULEB integer giving the length of the location description (see Section {singlelocationdescriptions}) that immediately follows.</p> </li> <li> <p>An address index operand is the index of an address in the <code>.debug_addr</code> section. This index is relative to the value of the <code>DW_AT_addr_base</code> attribute of the associated compilation unit. The address given by this kind of operand is not relative to the compilation unit base address.</p> </li> <li> <p>A target address operand is an address on the target machine. (Its size is the same as used for attribute values of class <code>address</code>, specifically, <code>DW_FORM_addr</code>.)</p> </li> </ul> <p>The following entry kinds are defined for use in both split or non-split units:</p> <ol> <li> <p><code>DW_LLE_end_of_list</code><br /> An end-of-list entry contains no further data.</p> <p><em>A series of this kind of entry may be used for padding or alignment purposes.</em></p> </li> <li> <p><code>DW_LLE_base_addressx</code><br /> This is a form of base address entry that has one unsigned LEB128 operand. The operand value is an address index (into the <code>.debug_addr</code> section) that indicates the applicable base address used by subsequent <code>DW_LLE_offset_pair</code> entries.</p> </li> <li> <p><code>DW_LLE_startx_endx</code><br /> This is a form of bounded location description entry (see page {bndlocdesc}) that has two unsigned LEB128 operands. The operand values are address indices (into the <code>.debug_addr</code> section). These indicate the starting and ending addresses, respectively, that define the address range for which this location is valid. These operands are followed by a counted location description.</p> </li> <li> <p><code>DW_LLE_startx_length</code><br /> This is a form of bounded location description entry (see page {bndlocdesc}) that has two unsigned LEB128 operands. The first value is an address index (into the <code>.debug_addr</code> section) that indicates the beginning of the address range over which the location is valid. The second value is the length of the range. These operands are followed by a counted location description.</p> </li> <li> <p><code>DW_LLE_offset_pair</code><br /> This is a form of {bounded location description} entry (see page {bndlocdesc}) that has two unsigned LEB128 operands. The values of these operands are the starting and ending offsets, respectively, relative to the applicable base address, that define the address range for which this location is valid. These operands are followed by a counted location description.</p> </li> <li> <p><code>DW_LLE_default_location</code><br /> The operand is a counted location description which defines where an object is located if no prior location description is valid.</p> </li> <li> <p><code>DW_LLE_include_loclistx</code><br /> This is a form of list inclusion, that has one unsigned LEB128 operand. The value is an index into the <code>.debug_loclists</code> section, interpreted the same way as the operand of <code>DW_FORM_loclistx</code> to find a target list of entries, which will be regarded as part of the current location list, up to the <code>DW_LLE_end_of_list</code> entry.</p> </li> </ol> <p>The following kinds of location list entries are defined for use only in non-split DWARF units:</p> <ol> <li> <p><code>DW_LLE_base_address</code><br /> A base address entry has one target address operand. This address is used as the base address when interpreting offsets in subsequent location list entries of kind <code>DW_LLE_offset_pair</code>.</p> </li> <li> <p><code>DW_LLE_start_end</code><br /> This is a form of bounded location description entry (see page {bndlocdesc}) that has two target address operands. These indicate the starting and ending addresses, respectively, that define the address range for which the location is valid. These operands are followed by a counted location description.</p> </li> <li> <p><code>DW_LLE_start_length</code><br /> This is a form of bounded location description entry (see page {bndlocdesc}) that has one target address operand value and an unsigned LEB128 integer operand value. The address is the beginning address of the range over which the location description is valid, and the length is the number of bytes in that range. These operands are followed by a counted location description.</p> </li> <li> <p><code>DW_LLE_include_loclist</code><br /> This is a form of list inclusion, that has one offset operand. The value is an offset into the <code>.debug_loclists</code> section, like the operand of <code>DW_FORM_sec_offset</code>. The offset identifies the first entry of a location list whose entries are to be regarded as part of the current location list, up to the <code>DW_LLE_end_of_list</code> entry.</p> </li> </ol> <hr /> <h1>Chapter <del>5</del><ins>6</ins>: Type Entries</h1> <p>…</p> <h2>6.7 Structure, Union, Class and Interface Type Entries</h2> <p>…</p> <h3>6.7.6 Data Member Entries</h3> <p>…</p> <p>For a <code>DW_AT_data_member_location</code> attribute there are two cases:</p> <ol> <li> <p>If the value is an integer constant, it is the offset in bytes from the beginning of the containing entity. If the beginning of the containing entity has a non-zero bit offset then the beginning of the member entry has that same bit offset as well.</p> </li> <li> <p>Otherwise, the value must be a location <del>description</del> <ins>expression</ins>. <del>In this case, the beginning of the containing entity must be byte aligned.</del> The <del>beginning address</del> <ins>location of the containing entity</ins> is pushed on the DWARF stack before the location <del>description</del> <ins>expression</ins> is evaluated; the result of the evaluation is the <del>base address</del> <ins>location</ins> of the member entry (see Section <del>2.5.1 on page 27</del> <ins>3.1</ins>).</p> <p><em>The push on the DWARF expression stack of the <del>base address</del> <ins>location</ins> of the containing construct is equivalent to execution of the <del><code>DW_OP_push_object_address</code></del> <ins><code>DW_OP_push_object_location</code></ins> operation (see Section <del>2.5.2.3</del><ins>3.6</ins>); <del><code>DW_OP_push_object_address</code></del> <ins><code>DW_OP_push_object_location</code></ins> therefore is not needed at the beginning of a location <del>description</del> <ins>expression</ins> for a data member. The result of the evaluation is a location<del>—either an address or the name of a register</del>, not an offset to the member.</em></p> <p><del><em>A <code>DW_AT_data_member_location</code> attribute that has the form of a location description is not valid for a data member contained in an entity that is not byte aligned because DWARF operations do not allow for manipulating or computing bit offsets.</em></del></p> </li> </ol> <p>…</p> <h3>Section 6.7.8 Member Function Entries</h3> <p>…</p> <p>An entry for a virtual function also has a <code>DW_AT_vtable_elem_location</code> attribute whose value contains a location expression yielding the <del>address</del> <ins>location</ins> of the slot for the function within the virtual function table for the enclosing class. The <del>address</del> <ins>location</ins> of an object of the enclosing type is pushed onto the expression stack before the location <del>description</del> <ins>expression</ins> is evaluated.</p> <p>…</p> <h2>6.14 Pointer to Member Type Entries</h2> <p>…</p> <p>The pointer to member entry has a <code>DW_AT_use_location</code> attribute whose value is a location <del>description</del> <ins>expression</ins> that computes the address of the member of the class to which the pointer to member entry points.</p> <p><em>The method used to find the address of a given member of a class or structure is common to any instance of that class or structure and to any instance of the pointer or member type. The method is thus associated with the type entry, rather than with each instance of the type.</em></p> <p>The <code>DW_AT_use_location</code> <del>description</del> <ins>expression</ins> is used in conjunction with the location <del>descriptions</del> <ins>expressions</ins> for a particular object of the given pointer to member type and for a particular structure or class instance. The <code>DW_AT_use_location</code> attribute expects two <del>values</del> <ins>elements</ins> to be pushed onto the DWARF expression stack before the <code>DW_AT_use_location</code> <del>description</del> <ins>expression</ins> is evaluated (see Section <del>2.5.1</del><ins>3.1</ins>). The first <del>value</del> <ins>element</ins> pushed is the value of the pointer to member object itself. The second <del>value</del> <ins>element</ins> pushed is the <del>base address</del> <ins>location</ins> of the entire structure or union instance containing the member whose <del>address</del> <ins>location</ins> is being calculated.</p> <hr /> <h1>Chapter <del>6</del><ins>7</ins>: Other Debugging Information</h1> <p>…</p> <h2>7.4 Call Frame Information</h2> <p>…</p> <h3>7.4.1 Structure of Call Frame Information</h3> <p>…</p> <p>The register rules are:</p> <p>…</p> <blockquote> <p>expression(E)<br /> The previous value of this register is located at the <del>address</del> <ins>location</ins> produced by executing the DWARF expression E (see <del>Section 2.5</del> <ins>Chapter 3</ins>).</p> </blockquote> <hr /> <h1>Chapter <del>7</del><ins>8</ins>: Data Representation</h1> <p>…</p> <h3>8.5 Format of Debugging Information</h3> <p>…</p> <h3>8.5.5 Classes and Forms</h3> <p>…</p> <ul> <li><del><code>locdesc</code></del> <ins><code>exprloc</code></ins><br /> A DWARF location <del>description</del> <ins>expression</ins> (see Section 2.<del>6</del><ins>5</ins>). This is represented as an unsigned LEB128 length, followed by a byte sequence of the specified length (<del><code>DW_FORM_locdesc</code></del><ins><code>DW_FORM_expression</code></ins>) containing the location expression.</li> </ul> </div> <!-- content --> </div> <!-- contentwrapper --> </body> </html>
|
