Issue 170427.2: Extending loclists
| Author: | Alexandre Oliva |
|---|---|
| Champion: | Ron Brender |
| Date submitted: | 2017-04-27 |
| Date revised: | 2021-04-27 |
| Date closed: | 2021-05-17 |
| Type: | Enhancement |
| Status: | Accepted |
| DWARF Version: | 6 |
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.
