[Dwarf-Discuss] Default Location List Entry Issue 130121.1

[Mark Wielaard]

On Wed, 2014-04-02 at 08:35 -0700, Michael Eager wrote:
> On 04/02/14 03:43, Mark Wielaard wrote:
> > On Tue, 2014-04-01 at 18:42 -0700, Michael Eager wrote:
> >> On 04/01/14 13:54, Mark Wielaard wrote:
> >>
> >>> 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.
> >>
> >> Both DW_AT_external attribute and a hypothetical DW_AT_global_scope
> >> attribute would describe scope, not the storage life of the object.
> >> C unfortunately has confabulated the two concepts.
> >
> > In practice I believe DW_AT_external does both and I have used it that
> > way to know whether to trust a single location description is globally
> > valid. But yes, just like lifetime both "external" and "scope" are again
> > bad words to use in this case and don't really express the thing we want
> > (they might only accidentally).
> 
> Section 3.3.1 describes the DW_AT_external with the following:
> 
>    If the name of the subroutine described by an entry with the tag
>    DW_TAG_subprogram is visible outside of its containing compilation
>    unit, that entry has a DW_AT_external attribute, which is a flag.
> 
> Section 4.1 contains the following (describing an object):
> 
>    2. A DW_AT_external attribute, which is a flag, if the name of a
>    variable is visible outside of its enclosing compilation unit.
> 
> There is nothing about the lifetime of any object.  Confabulating that
> the scope attributes in DWARF imply something different is not supported
> by the DWARF standard and will lead to misinterpretation of the DWARF standard.
>
> > What about we call the flag attribute DW_AT_global_visible or
> > DW_AT_global_location then it would be clear I think because it signals
> > this isn't about language or DWARF tree (lexical) scoping?
> 
> Symbol visibility is adequately described by the DW_AT_external attribute
> as defined above.  Object locations are adequately described by location
> expressions and location lists.

I cannot tell whether we are in violent agreement or disagreement.
Probably both :) I guess the confusion comes from some misunderstanding
about assumptions of terminology used.

As was said before the term lifetime as used in the description of
location descriptors is confusing. Since DWARF doesn't talk about
lifetime of objects anywhere else. What I seem to miss is how to express
for a data object the address ranges where a a location description is
valid for single location descriptions. I think it would really help if
the use of "lifetime" in the definition of location descriptors was
dropped and clarified by a definition based on valid address ranges.

But maybe I am just misunderstanding something by reading too much or
too little in this definition. I'll ask for a more specific example
below so we don't have to argue about the specifics of words/definitions
but can just agree on what a producer should emit for an consumer to
know which ranges are valid.

> >> Objects which have only a single location can be described with a location
> >> expression.  They don't need a location list with a default entry.
> >
> > For a data object that has a single location descriptor (DW_AT_location
> > in exprloc class form), the valid range is given by the address ranges
> > of the DIEs that own the data object. So it only lets me express the
> > location in a restricted range. I do need to use a location list with
> > (just) a default entry if I want to indicate that the location
> > description has a valid global range.
> 
> No, this interpretation is incorrect and is not supported by reading the
> DWARF Standard.  Please see Section 2.6.
> 
> Perhaps you are confused by the following from Section 2.6 (which I think
> is unambiguous):
> 
>     1. Single location descriptions, which are a language independent
>        representation of addressing rules of arbitrary complexity built
>        from DWARF expressions and/or other DWARF operations specific to
>        describing locations. 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.
> 
> You seem to have interpreted "either/or" in the second sentence to mean "and".

You are correct that I am confused about this definition. Not because of
the either/or but about how to express the choices in DWARF. I don't
understand how for a DWARF Data Object DIE I express whether a) its
lifetime is static or b) the lifetime is the same as the lexical block
that owns it.

I assume that a "static lifetime" means the single location description
of the Data Object DIE is valid for all address ranges. And I assume a
"lifetime that is the same as the lexical block that owns it" means that
the ranges for which the single location description is valid are the
same as the ranges of the owning Program Scope DIE of the Data Object
DIE.

> > Is the above correct? Or is there another way to express that a location
> > description is globally valid? Or am I misunderstanding the purpose of
> > having a default entry in a location list?
> 
> You do not need a location list for a static object.  A simple location
> expression will suffice.

Could you give an example of how to express a static object in DWARF
with a simple location description? And how does a consumer know the
valid range of the simple location expression in that example is global
and not the same as the lexical block that owns the Data Object DIE?

> A default location list entry (as proposed in 130121.1) gives the location
> of an object for address values which are not otherwise specified in the
> location list.

Maybe an example of this would be helpful too. I am under the (wrong)
impression that a default location list entry would be used to describe
"static objects". But the use case is probably different than I imagine.

Thanks,

Mark