[Dwarf-Discuss] Default Location List Entry Issue 130121.1

[Michael Eager]

On 03/30/14 14:39, Mark Wielaard wrote:
> Hi,
>
> I was reading the DWARF5 proposal Issue 130121.1 Default Location List
> Entry http://dwarfstd.org/ShowIssue.php?issue=130121.1 and was wondering
> how to interpret the phrase "(provided that address is within the
> containing module)" from the introduction.
>
> In the actual text of the proposal there is no limit imposed on the
> default location list entry. It is just described as an unlimted number
> of address ranges, none of which overlap any of the addresss ranges
> defined earlier in the same location list.
>
> So I was wondering whether any limitation is implied or not. For example
> a Data Object DIE that has a DW_AT_location loclistptr that includes a
> default entry. Would the default entry address ranges of the default
> location list entry be constrained by the owning DIE of the Data Object
> (given by the DW_AT_low_pc and DW_AT_high_pc pair or DW_AT_ranges
> attribute in that owning DIE)? Or does the presence of the default entry
> imply that the location of the Data Object keeps valid even outside the
> owning DIE range (for example because it is a static C variable inside a
> function)?

A default location list entry is a single location, as described in the
proposal.  It is not a list of address ranges.  (Perhaps you mean that
the location list is a sequence of non-overlapping address ranges?)

The location list entries (including the default) are not constrained to
be within the range of the containing DIE.

The proposal creates a DWARF idiom, saying that a particular object can
be found at all (valid) PC locations.  A producer might instead create a
default location list entry for a static object within a function which
had the range of the function (i.e., the containing DIE), the compilation
unit, or perhaps the entire executable.  All of these would likely be
reasonable descriptions of the object, from different points of view,
although they might give different behaviors in a debugger.

-- 
Michael Eager	 eager at eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077