[Dwarf-Discuss] Default Location List Entry Issue 130121.1

[Mark Wielaard]

On Mon, 2014-04-07 at 08:30 -0700, Michael Eager wrote:
> 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.

Agreed, as long as consumers can reliably interpret the valid ranges for
the location expression.

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

Of course it doesn't need to use a DW_AT_start_scope, it can also use a
location list, generate an extra narrower lexical block that owns the
data object DIE, or maybe not generate any of that at all. The point was
that the intention of what the valid ranges of the default entry are in
cases when such attributes are generated are clearly documented.

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

It is not just when the stack frame is created but also when which stack
slots are seeded with the actual values (and a compiler using shrink
wrapping might sprinkle the frame setup and allocations throughout the
function). That is precisely why a DWARF producer can use attributes
like DW_AT_start_scope, use an lexical block with narrower scope or use
location lists to indicate over which address range a location
expression is valid. I just want to make it clear how these attributes,
when used by a producer to guide a consumer, interact with the default
entry proposal.

Cheers,

Mark