Issue 130121.1: Default Location List Entry
Section 2.6.2
Introduction
------------
Recent discussions regarding "Address computation overflow" in
location lists (Issue 110120.1) have concluded that the example
location list entry considered, which has beginning and ending
addresses of 0 and -1, respectfully, is not valid DWARF because
it purports to express entity location information that applies
outside of its containing compilation module.
However, there is utility in defining this form as a special
case "idiom" that expresses a default location that applies if
no earlier entry in a location list entry includes an address
of interest (provided that address is within the containing
module).
Proposal
--------
1) In Section 2.6.2, in the third paragraph, replace "A location
list entry consists of:" with
"A location list entry has two forms: a normal location list
entry and a default location list entry.
"A normal location list entry consists of:"
2) Following bullet 3 on page 31, insert "normal" in the next
sentence so that it begins "The applicable base address of a
normal location list entry..."
3) In paragraph 5 on page 31, replace "Address ranges may overlap."
with
"Address ranges defined by normal location list entries may
overlap."
4) Following that same paragraph and before the paragraph that
defines base selection entry, insert the following:
"A default location list entry consists of:
1. The value 0.
2. The value of the largest representable address offset (for
example, 0xffffffff when the size of an address is 32 bits).
3. A single location description describing the location of the
object when there is no prior normal location list entry
that applies in the same location list.
"A default location list entry is independent of any applicable
base address (except to the extent to which base addresses
affect prior normal location list entries).
"A default location list entry must be the last location list
entry of a location list except for the terminating end of list
entry.
"A default location list entry describes an unlimited number
(zero, one or more) of address ranges, none of which overlap
any of the address ranges defined earlier in the same location
list. Further, all such address ranges have the same simple
location."
5) Prior to the last (italics) paragraph on page 32, insert the
following:
"*When a DWARF consumer is parsing and decoding a location
list, it must recognize the beginning and ending address
offsets of (0, 0) for an end of list entry and (0, "-1") for
a default location list entry prior to applying any base
address. Any other pair of offsets beginning with 0 is a
valid normal location list entry. Next, it must recognize the
beginning address offset of "-1" for a base address selection
entry prior to applying any base address. The current base
address is not applied to the subsequent value (although there
may be an underlying object language relocation that affects
that value).*"
Discussion
----------
There is considerable discussion of related issues, including the
possibility of this interpretation, in emails under the subject
"[Issue 110120.1] Address computation overflow" dating back to at
least September 2012 (authors Coutant, Anderson, Eager, et al). I
will not try to recapitulate those discussions here.
There is one minor backward imcompatibility to note: The (0, -1)
address range is redefined from what nominally used to be a (normal)
location list entry (now judged to be "bad DWARF") to be a new kind
of entry, namely, a default location list entry. This seems not a
problem.
I do note that the default location list concept was implemented
in the DWARF on Itanium VMS (using exactly the representation above)
as well in vendor-specific predecessor debugging representations
for VAX/Alpha VMS and Ladebug on Alpha Unix during my tenure at
DEC/Compaq/HP.
---
Accepted 2/12/2013 with change of "simple location" to "single location"
in item 4..
