[Dwarf-Discuss] Default Location List Entry Issue 130121.1

[Mark Wielaard]

On Mon, Mar 31, 2014 at 03:14:51PM -0700, Michael Eager wrote:
> On 03/31/14 10:59, Mark Wielaard wrote:
> 
> >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?
> 
> Static means that the object is created when the program is instantiated,
> generally by being allocated a defined location by a linker and then loaded
> into memory.  The lifetime of the object is from when the program is
> started to when it terminates, or as long as the memory space is extant.
> 
> The use of the term lifetime may be a bit misleading in the DWARF
> context, since it implies that DWARF is describing dynamic behavior
> (at least, birth and death) when it only describes static characteristics
> of a program.  The address ranges (whether low/high PC or location
> lists) specify the values of the PC where the associated information is
> valid.  If the current PC (or the PC on the current call chain) is within
> the range, then the information is valid, otherwise it is (under certain
> circumstances) not.

That is a good explanation of what is meant in 2.6 for when to use a
single location description versus when to use a location list because
it reuses other DWARF definitions. I would suggest to remove the reference
to lifetime there. And to add something like the last two sentences instead
to describe when to use which and to describe the ranges over which they
are valid.

> Your alternate interpretation may be equivalent under some circumstances,
> but not under others.  For example, if you have a program with multiple
> CUs (most programs), each of which has static memory, there may be times
> during the program's execution when the current PC (or any call chain PC)
> does not fall within the low/high PC for a given CU.  Still, if you stop
> the program with a debugger, the static data for for that CU is valid.

What about using the presence of a DW_AT_external attribute on the data
object that has a single location expression to know whether the described
location is valid/visible outside of the enclosing lexical scope?

Using that or some new flag (DW_AT_global_scope) to mark a data object
that has a single location description with global scope might be cheaper
than encoding it with a location list pointer and a default entry.

Cheers,

Mark