[Dwarf-Discuss] Default Location List Entry Issue 130121.1

[Mark Wielaard]

On Mon, 2014-04-07 at 09:07 -0700, Michael Eager wrote:
> On 04/07/14 05:28, Mark Wielaard wrote:
> > On Thu, 2014-04-03 at 08:26 -0700, Michael Eager wrote:
> >> On 04/03/14 01:51, Mark Wielaard wrote:
> >>> 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.
> >>
> >> Consider a lexical block or function in C which has the following:
> >>
> >> A data object X which is defined as
> >>     static int X;
> >> would have a static lifetime.  It is created when the program is loaded
> >> and is valid for the entire duration that the program runs.
> >>
> >> Another data object Y is defined as
> >>     register int Y;
> >> would (most likely) be allocated to a register.  This object is created
> >> when the lexical block or function is entered and is destroyed when the
> >> function exits.  Its location would only be valid while the execution PC
> >> is located within the range specified by the low_pc/high_pc of the enclosing
> >> lexical block.
> >>
> >> Both of these objects can be described as a simple location expression.
> >
> > OK, so for both you can use a simple location expression for describing
> > the location of the value. But there is no easy way to distinguish
> > these. The valid range(s) of these two location expressions are
> > different, which is what matters to a consumer. Without having a way to
> > distinguish them I assumed consumers would interpret the location
> > expression as only valid for the smallest range possible (given by the
> > enclosing DIE and DW_AT_start_scope).
> 
> You may make whatever assumptions you wish, but they are not contained in
> the DWARF specification.  We make every attempt to be precise in the DWARF
> specification.  If something is not stated explicitly in the DWARF specification,
> I caution you not to assume that it exists, and conversely, when something
> is stated explicitly, I caution you not to assume that it does not apply.
> 
> Repeating your incorrect assumption about containing scope constraining
> a location description doesn't make it correct.

When two people having worked with DWARF for some time come to different
assumptions about what the standard means then we can at least conclude
that the standard is somewhat ambiguous and could use clarification. I
think it is important for DWARF consumers to know over what address
ranges a producer meant a location expression to be valid. Since trying
to interpret it outside that valid range might provide the user with a
bogus value without warning.

Our disagreement seems to simply come from whether there is any specific
meaning to saying the lifetime of an object is the same as the lexical
block that owns it and having ways to describe specific lexical blocks
that can be constrained by attributes like DW_AT_start_scope which talk
about scope smaller than the enclosing object.

But maybe it is all mood and we are simply talking slightly past each
other. You seem to focus on whether a location expression on its own is
constrained (and without any context I would agree it is not). While I
focus on whether it makes sense to interpret a location expression for a
specific data object out of the scope that the producer created for it
(and that really only seems to make sense for static/global objects, but
DWARF doesn't seem to have a simple way to express that since every data
object is always defined inside a specific DIE that owns it).

So maybe what we are really arguing about is how to best express a
static data object in DWARF.

> >> When you are interpreting the DWARF description for an object, you can
> >> only determine whether a location expression is valid by interpreting it.
> >> At different times during a program's execution, a location expression may
> >> be valid and at other times it may be invalid.  If the location is dependent
> >> on values which are dependent on the lexical block (e.g., a register value
> >> which is only valid within the block, or an offset from the stack frame)
> >> then the location expression is only valid if the execution PC is within
> >> the lexical block (for a register value) or if the frame can be found by
> >> walking the stack (for the offset case).  If the expression doesn't require
> >> information dependent on the lexical block (i.e., the object has static
> >> lifetime), then it is always valid.
> >
> > That is an interesting approach. I would not have guessed that from the
> > DWARF specification. So it would be good to document this somewhere.
> 
> We assume that people reading the DWARF specification have experience
> in generating and/or consuming debug information, and that they have experience
> in developing debuggers.  We do not feel a compelling need to describe
> every possible implication of running a program under a debugger.

I have experience from working on debuggers, tracers, profilers and
static/dynamic analyzing tools using DWARF information. And it hadn't
occurred to me that a DWARF producer would express the static/global
scope of a data object through the specific location expression
operations it attached to it. So I still think it would be good to
explicitly document such things somewhere. If only to make sure DWARF
producers and consumers interpret such things in the same way.

> > Having a class of DWARF operands that can not be used to describe an
> > data object value that has a globally valid range. Then a consumer could
> > determine when it can validly interpret a location description outside
> > the local scope:
> >
> > 1) If it is a location list or the data object has a DW_AT_start_scope
> > attribute, the valid range is not global.
> > 2) If the location expression uses any Register Based Addressing
> > operations, DW_OP_call_frame_cfa, a register name operation
> > or uses DW_OP_call2, DW_OP_call4, DW_OP_call_ref which reference one of
> > the earlier operands, then the valid range is not global.
> >
> > Did I miss any operand/classes?  Or is there an easier way to determine
> > the class of DWARF expressions that are valid outside the local scope?
> 
> This seems to have been answered.  If you evaluate a location expression
> and it uses a value  which is not defined (e.g., frame pointer), then the
> expression is invalid.
> 
> You may be misunderstanding the DW_OP_call2, DW_OP_call4, DW_OP_call_ref
> operations.

Maybe. I have not seen any output from DWARF producers using them. How
do you think I am misunderstanding them?

> > I think that could work, but is a little cumbersome for consumers, since
> > it means to interpret all DWARF descriptions for all objects. I do think
> > having an explicit attribute flag would be easier to work with.
> 
> This appears to be a QoI issue.  I'm not sure exactly what you mean by
> "interpret all DWARF descriptions for all objects".  It seems to me that a
> debugger would only need to interpret the location of an object when asked
> to display its address or value.  DWARF does not place any constraints on
> when you interpret the location information, so you can interpret this when
> needed, or interpret all at once, or anywhere in between.

The use case I had in mind is the opposite. A user asking for all data
objects that can be displayed at some point. But is probably hard either
way, you'll still need to scan through the CUs to get either the
attributes or the location descriptions of the data object DIEs. It is
just that interpreting an attribute flag is slightly cheaper than
interpreting the location expression. A cheap solution for that use case
is probably completely independent from our current discussion of how to
interpret the valid address ranges of a location expression.

Cheers,

Mark