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 ea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
_______________________________________________
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
