[Dwarf-Discuss] Default Location List Entry Issue 130121.1

[Michael Eager]

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.

There should be no difficulty you have in distinguishing a static variable
from one in a register.  They are explicitly described in a location expression.

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

No, it only has the meaning that the DWARF specification prescribes,
nothing else.

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

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

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

-- 
Michael Eager	 eager at eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077