On Mar 12, 2019, Jakub Jelinek <ja...@redhat.com> wrote: > Note, for DWARF before v4, there is no DW_FORM_sec_offset and > DW_FORM_data4 or DW_FORM_data8 depending on whether it is 32-bit or 64-bit > DWARF is used instead.
Ah, yes, thanks. I made these fixes, changed some dashes to underlines in "identifiers", and uploaded it for now to the end of https://people.redhat.com/aoliva/papers/sfn/dwarf6-sfn-lvu.txt ============================= 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<n> (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<n> (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<n>, DW_FORM_udata, or even DW_FORM_implicit_const. If this attribute is omitted, the entry point view number should be taken as zero. -- Alexandre Oliva, freedom fighter https://FSFLA.org/blogs/lxo Be the change, be Free! FSF Latin America board member GNU Toolchain Engineer Free Software Evangelist Hay que enGNUrecerse, pero sin perder la terGNUra jamás-GNUChe