[Dwarf-Discuss] Default Location List Entry Issue 130121.1

[Mark Wielaard]

On Mon, 2014-03-31 at 08:39 -0700, Michael Eager wrote:
> On 03/30/14 14:39, Mark Wielaard wrote:
> > 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?)

Yes.

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

OK, that makes some sense for normal location list entries. But it isn't
immediately obvious for the default entry (IMHO). Better to be explicit
about it if that is the case.

> The proposal creates a DWARF idiom, saying that a particular object can
> be found at all (valid) PC locations.

OK.

> 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.

So the new default location list entry expresses something that couldn't
be expressed before? In that case not limiting the range of the default
entry makes complete sense.

I had assumed before that a Data Object with a single location
expression DW_AT_location attribute (encoded using class exprloc) could
be assumed either to have a lifetime of the lexical block that contained
it, or that it would be static if declared as child of the top-level CU.

My interpretation comes from 2.6 Location Descriptions, item 1. Single
location descriptions which says "They are sufficient for describing the
location of any object as long as its lifetime is either static or the
same as the lexical block that owns it, and it does not move during its
lifetime." But another interpretation would be that the lifetime of a
variable defined as child of a CU has as lifetime for its single
location descriptor the range of the CU that contains it (assuming the
CU is just another lexical block).

I now think that my confusion is not with this new definition of a
default entry. But with how to interpret the word "lifetime" in 2.6
Location Descriptions. When is that lifetime assumed to be static?

Thanks,

Mark