[Dwarf-Discuss] Default Location List Entry Issue 130121.1
mjw at redhat.com
Mon Apr 7 05:28:14 PDT 2014
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).
> There may be other ways to describe these objects using location lists,
> perhaps with a default, but there is no compelling reason to do this.
I see. I was hoping the default entry in a location list would signal
the difference between a local and global valid range for a data object.
> 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.
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?
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.
More information about the Dwarf-Discuss