[Dwarf-Discuss] Default Location List Entry Issue 130121.1

[Michael Eager]

On 04/07/14 03:04, Mark Wielaard wrote:
> OK. It would be good to mention that explicitly (and how to make clear
> how to distinguish local variables from global ones, but that is the
> subject of the other thread in this discussion). Since the range can be
> read as if it was valid outside the range of the containing lexical DIE
> if it is a default entry. And it isn't immediately clear to me from the
> text whether producers are supposed to only generate location list
> ranges that fall within the address range of the containing
> subprogram/lexical block, or that the consumer is supposed to make sure
> to only use the ranges that are valid for the address range of the
> containing subprogram/lexical block DIE.

Part of DWARF's philosophy is to describe exactly what the DWARF
specification means but not prescribe how producers should generate
DWARF.  We do give guidance on how particular DWARF tags or attributes
might be used when their application might not be clear.

A producer that generates location lists in either of the ways you
describe would (as far as I can see) be generating correct DWARF.

>> Well, technically
>> only for the address range that has a valid stack frame.
>
> In the case that the range is smaller than the scope of the most
> enclosing object the producer should add a DW_AT_start_scope for the
> data object to indicate where the ranges for the data object are valid.
> That seems to apply in this case too, wouldn't it? If so, it would again
> be good to explicitly mention that the valid range of the default entry
> are constrained by this, so consumers don't interpret it in ranges that
> aren't valid.

A producer can generate whatever attributes it wishes, so long as they
have the meaning prescribed by the DWARF specification.  There is nothing
in the DWARF specification which says that a producer should (or should
not) generate a DW_AT_start_scope for each local variable.  This is a
Quality of Implementation (QoI) issue.

The default location list entry is not constrained in any fashion.

One may assume that debugger developers have an understanding of the
calling sequence for a function and that they are aware that locations
which are described as being on a stack frame are not valid until the
frame is created.  With that assumption, a producer can generate a simple
location expression describing a object as some offset within the frame.
Alternately, a producer might assume that debugger developers do not know
anything about call sequences or call frames and generate a location list
which more precisely describes the locations where a frame-based object is
valid, from the time the frame is created to when it is destroyed.
(Much of that information is in the DWARF CFI data.)

DWARF does not specify which assumption a producer must make.  Quality
of Implementation (QoI) issues are explicitly outside the domain of the
DWARF specification.

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