Proposals submitted as enhancements to the DWARF committee after DWARF5. http://lists.dwarfstd.org/private.cgi/dwarf-discuss-dwarfstd.org/2017-April/004347.html ======================= Location View Numbering ======================= This proposal introduces a new implicit column to the line number table, namely "view numbers", so that multiple program states can be identified at the same program counter, and extends loclists with means to add view numbers to address ranges, enabling locations to start or end at specific views. This may improve debug information, enabling generators to indicate inlined entry points and preferred breakpoints for statements even if instructions associated with the corresponding source locations were not emitted at the given PC, and to emit variable locations that indicate the initial values of inlined arguments, and side effects of operations as they would be expected to take effect from the source code, even when multiple statements have their side effects all encoded at the same PC: with view numbers, debug information consumers may be able to logically advance the perceived program state, so as to reflect user-expected changes specified in the source code, even if the operations were reordered or optimized out in the executable code. View numbers ------------ In Section 6.2, page 149, line 4: change "with one row" to "with at least one row". Before line 11, add a bullet "a view number, identifying a logical program state". In Section 6.2.2, page 150, add to Table 6.3, between 'address' and 'op_index', a new register named "view", defined as "An unsigned integer that identifies each distinct entry associated with the same 'address' in the line number matrix." In Section 6.2.2, page 152, add before line 1 the following sentence: "The address and view registers, taken together, identify a logical state within the source program." In Section 6.3, page 153, add to Table 6.4 a line "view | 0" after address. In Section 6.2.5, page 160, add a Subsection "6.2.5.0 View Numbers": View numbers identify multiple logical states of the source program that are all associated with the same address in the program. View numbers are computed as a side effect of line number opcodes, observing the following rules: * opcodes that modify the address register (with the exception of DW_LNS_fixed_advance_pc) simultaneously reset the view register to zero * opcodes that append a row to the matrix subsequently increment the view register Rationale: location lists can refer to address and view, not op_index, so views are reset at address changes, not at op_index changes. Opcodes that advance op_index only will only reset the view when they happen to advance the address, e.g. by exceeding maximum_operations_per_instruction in op_index. DW_LNS_fixed_advance_pc is the only opcode that may change the address without resetting the view. It is available for compilers to use when an address change is uncertain, e.g., when advancing past opcodes that may expand to an empty sequence, e.g. possibly-empty alignment sequences, optional no-operation opcodes or the like. In Section 6.2.5.1, page 160, insert before item 3: "Reset the view register if the value of the address register changed in 2.", and after item 3: "Increment the view register" In Section 6.2.5.2, page 162, 1. DW_LNS_copy, line 10, add after "Then it": "increments the view register, ". In Section 6.2.5.2, page 162, append to the description of 2. DW_LNS_advance_pc: "Then, if the value of the address register changed, it resets the view register to zero." In Section 6.2.5.2, page 163, append to the first paragraph of 8. DW_LNS_const_add_pc: ", and it resets the view register to zero if the value of the address register changed." In Section 6.2.5.2, page 163, add a third paragraph to 9. DW_LNS_fixed_advance_pc: "This is the only address-changing opcode that does NOT reset the view register. It helps compilers that emit line number programs to determine view numbers even when advancing past opcodes that might expand to nothing." In Section 6.2.5.3, page 164, in 2. DW_LNE_set_address, change "op_index register" to "view and op_index registers". Views in loclists ----------------- In Section 2.6.2, page 43, add a bullet before "Default location description": * View description. This kind of entry must precede a Bounded location description, and it augments the starting and ending address of the Bounded location description with [view numbers|link to 6.2.5.0]. The addresses of a bounded location description that is not preceded by a view description are argumented with view number zero. In Section 2.6.2, page 45, add before 6++. DW_LLE_default_location: 6. DW_LLE_view_pair This is the only form of view description, and it has two unsigned LEB128 operands. The first and second values specify respectively the view numbers that augment the starting and ending addresses of the bounded location description the view description precedes. In Section 7.7.3, add to Table 7.10 the following entry: DW_LLE_view_pair | 0x09 ---- ================== Extending loclists ================== This proposal introduces an extension mechanism to loclists, that can be used to share location list fragments among multiple location lists, and to experiment with extensions to location list standards in a way that does not break backward compatibility and that enables the experimental extensions to be welcomed into the standard without encoding changes. In Section 2.6.2: * List extension. This kind of entry extends a location list with entries from another loclist. It can be used to share list entries among multiple lists, and also to extend location lists with nonstandard entry kinds, in a way that will be disregarded by debug information consumers that do not support the extensions. In Section 2.6.2, page 44, add to 1. DW_LLE_end_of_list: Any non-standard entry kind may be interpreted as a DW_LLE_end_of_list entry. 2. DW_LLE_extend_loclistx This is a form of list extension, that has one unsigned LEB128 operand. The value is an index into the .debug_loclists section, like the operand of a DW_FORM_loclistx loclist. The contents of the location identified by the index are added to the base to determine the address of the first entry of a loclist whose entries are to be regarded as part of the loclist containing the list extension entry. In Section 2.6.2, page 45, add after 9. DW_LLE_start_length: 10. DW_LLE_extend_loclist This is a form of list extension, that has one offset operand. The value is an offset into the .debug_loclists section, like the operand of a DW_FORM_sec_offset loclist. The offset identifies the first entry of a loclist whose entries are to be regarded as part of the loclist containing the list extension entry. In Section 7.7.3, add to Table 7.10: DW_LLE_extend_loclist | 0x0A DW_LLE_extend_loclistx | 0x0B ============================= Extensions for DWARF v2 to v5 ============================= This section documents how location views are implemented as extensions to earlier versions of DWARF. Being backports of the proposed extensions above, these were NOT submitted to the DWARF committee. View number assignment takes place in the line number table, just as proposed above. Attributes and Forms -------------------- Location lists are not extensible in DWARF up to v5 in a backward compatible way. Thus, augmenting them with view lists relies on a separate optional attribute: DW_AT_GNU_locviews | 0x2137 This attribute should only be present in a DIE that has a DW_AT_location attribute that references a location list, rather than a single location. If this attribute is omitted, the view numbers associated with any implied or explicit location ranges in the location are to be taken as zero. Locviews lists, referenced by DW_AT_GNU_locviews attributes, are to be placed in the same section as the location lists. When location lists are referenced in DW_AT_location attributes by an absolute address in DW_FORM_sec_offset (DWARF v4) or DW_FORM_data (DWARF up to v3), the corresponding DW_AT_GNU_locviews attribute can be of the same form, with an absolute address as well. When generating split (extension to) DWARF up to v4, DW_AT_location is represented with an offset from the base address in the beginning of the .debug_loc.dwo section, in DW_FORM_sec_offset (DWARF v4) or DW_FORM_data (DWARF up to v3). DW_AT_GNU_locviews should then be an offset from the same base address, also of the same form. When generating split DWARF v5, DW_AT_location is given in DW_FORM_loclistx, an offset, from the base address after the .debug_loclists section header, that in turn holds the offset, from the same base address, of the beginning of the actual location list. DW_AT_GNU_locviews attributes that augment such location lists shall use a DW_FORM_sec_offset value, to be interpreted as an offset from the same base address, rather than from the beginning of the .debug_loclists section. For split DWARF v5, it is not recommended for DW_AT_GNU_locviews to use DW_FORM_loclistx. Having entries in the loclists index table referencing locviews rather than loclists might surprise some consumers, and using out-of-range indirect addresses instead of index table entries might also surprise them for out-of-range indexing of the table and for not ultimately referencing a location list. Separate Locviews lists ----------------------- The locviews list is represented as a sequence of pairs of uleb128 numbers, each pair corresponding to an address range in the location list, i.e. not including the terminator, in DWARF up to v4, and covering only bounded location descriptions in DWARF v5. The view numbers pairs are matched to address ranges in the order they appear. Where a proposed DWARFv6 combined location+view list could be represented as: DW_LLE_base_address base_address DW_LLE_view_pair V1, V2 DW_LLE_start_end A1, A2, location_expression DW_LLE_start_end A3, A4, location_expression DW_LLE_view_pair V5, V6 DW_LLE_start_length A5, L6, location_expression DW_LLE_default location_expression DW_LLE_end_of_list ... the locview list output separately for DWARF up to v5 would be: V1, V2, 0, 0, V5, V6 for a DWARFv5 location list like the v6 one above, minus the DW_LLE_view_pair entries. The view pair for A3 and A4, that could be omitted in the combined v6 list, has to be explicitly put in up to v5, because for each bounded location description, there must be a pair of corresponding view numbers to be matched to the pair of addresses given by it. Up to DWARFv4, the location list matching the locview list above would look as follows: -1, base_address A1, A2 location_expression A3, A4 location_expression A5, A5+L6 location_expression (a default expression cannot be represented) 0, 0 ======================== Inlined Entry Point View ======================== This extension proposal is yet to be submitted to the DWARF committee. Optimizing subprograms into which a subroutine was inlined, the entry point of an inlined subroutine may be at an address associated with other views, in the enclosing subprogram, in the inlined subroutine, or even in other inlined subroutines. It may thus be useful to indicate which of the views associated with the entry point address logically corresponds to the view in which execution of the inlined subprogram begins, so that, when a breakpoint is set at the entry point, a debugger knows to advance to the entry point view: locations for the parameters are not expected to be bound in earlier views. The view number for the entry of the inlined subroutine can be named in the DW_TAG_inlined_subroutine DIE, along with the DW_AT_entry_point attribute or other means that specify the entry point. DW_AT_GNU_entry_view | 0x2138 The view number shall be represented as an unsigned constant, using such forms as DW_FORM_data, DW_FORM_udata, or even DW_FORM_implicit_const. If this attribute is omitted, the entry point view number should be taken as zero.