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

[Alexandre Oliva <aoliva at redhat dot com>]

On Mar  9, 2019, Alexandre Oliva <aoliva@redhat.com> wrote:

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