[PATCH] Fix -gdwarf-5 -gsplit-dwarf ICEs (PR debug/89498)

[Alexandre Oliva]

On Mar 12, 2019, Jakub Jelinek <jakub@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