DWARF Standard

The original proposal sought to add some new kinds of location
list entries (LLEs). To deal with upward compatibility issues it
proposed:

  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.

This approach has numerous issues:

  . It is not consistent with the vendor-defined extensions model
    used elsewhere in DWARF.
  . It will interfere with potential DWARF extensions because user
    extension kind codes are not segregated.
  . It actually doesn't work--from a consumer perspective, any
    unknown code is a show stopper, whether "authorized" or not.
There is no reasonable way to skip over the unknown entry and
resume following.

This replacement proposal defines a vendor-specific extension range
for LLEs. Further, because range lists and locations lists are
strongly similar in structure and organization, a similar extension
range is defined for them as well.

TEXT CHANGES

1) In Section 7.1, p 183, lines 13-14, add "DW_LLE" and "DW_RLE"
in  the (alphabetical) list of prefixes that have vendor-defined
extension ranges.

2) In Section 7.7.3, p226, Table 7.10, add

    DW_LLE_lo_user    0xc0
    DW_LLE_hi_user    0xff


3) In Section 7.25, p240, Table 7.30, add

    DW_RLE_lo_user    0xc0
    DW_RLE_hi_user    0xff

A limitation of the above is that it does not address
how to assure that a vendor extension can be skipped if not known to a
consumer. The simplest strategy appears to be
to require that the beginning of an extended function be a ULEB length
of any operands (whether zero or more) that follow. The following
text changes (in addition to the changes above) express this:

4) In Section 7.7.3, following Table 7.10, insert the following:

    "If a vendor defines a vendor-specific kind of location list
entry, the kind code must be immediately followed by an
unsigned LEB128 value that specifies the length of all
remaining bytes (not including either the kind or the length
itself) for that entry."

5) In Section 7.25, following Table 7.30, insert the following:

    "If a vendor defines a vendor-specific kind of range list
entry, the kind code must be immediately followed by an
unsigned LEB128 value that specifies the length of all
remaining bytes (not including either the kind or the length
itself) for that entry."


NOTE: By editorial convention, all four entries will be marked with
double-dagger symbols indicating they are "New in DWARF Version 5".

--
2021-04-15:  Revised and split into two proposals.  See 170427.3.
   Previous version: http://dwarfstd.org/issues/170427.2-1.html
2021-04-27:  Added items (4) and (5).
2021-05-17:  Accepted.