On Mar 9, 2019, Alexandre Oliva <aol...@redhat.com> wrote: > On Mar 9, 2019, Jakub Jelinek <ja...@redhat.com> wrote: >> If so, then all we need is likely my patch + some documentation change, >> though not sure where exactly it should be documented, some Wiki we refer >> in include/dwarf2.def, or what?
> Hmm, I was thinking of placing it next to dwarf6-sfn-lvu.txt in > https://people.redhat.com/aoliva/papers/sfn/ but there seem to be > several extensions documented in the GCC wiki, so I guess I could do > that instead, or as well. I'll take care of it, and post back when I'm > done. Here's a draft description of the representation of locviews in DWARF up to 5, and, while at that, of DW_AT_GNU_entry_view, to be appended to dwarf6-sfn-lvu.txt (and possibly massaged into the wiki). Please let me know if it's sufficiently descriptive and clear, or if you find anything missing, wrong, unclear or otherwise improvable. Thanks in advance, ============================= Extensions for DWARF v2 to v5 ============================= This section documents how location views are implemented as extensions to earlier versions of DWARF. 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, the corresponding DW_AT_GNU_locviews attribute can be a DW_FORM_sec_offset 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. DW_AT_GNU_locviews should then be an offset from the same base address, also in DW_FORM_sec_offset. 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 only bounded location descriptions in DWARF v5. The view numbers are assigned 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-epxression 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 (the default expression cannot be represented) 0, 0 ======================== Inlined Entry Point View ======================== 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
