[Dwarf-Discuss] Default Location List Entry Issue 130121.1

[Mark Wielaard]

Hi Paul,

On Thu, 2014-04-03 at 13:46 +0000, Robinson, Paul wrote:
> Consider a subprogram with a local stack-allocated variable.  In the
> simple case, a simple location description gives that location, and
> of course it's valid for the address-range of the containing subprogram.
> 
> The compiler might optimize this variable into a register for part of
> the subprogram, a different register for a different part of the
> subprogram, and leave it on the stack otherwise.  This can be described
> by a set of normal location list entries for the ranges where the
> variable is in a register, and a default location entry for the entire
> range of the subprogram, giving the stack location.  Of course the 
> compiler *could* emit many individual entries with the stack location,
> filling in the gaps, but the default location entry is more compact.

Thanks for the example and sorry for the long discussion afterwards that
I think doesn't directly address my concern about how to interpret the
default location entry in a consumer. Although an interesting
discussion, it also turned into a somewhat abstract theoretical
discussion about the definition of "scope" and the definition of "valid
address", which probably obscured my more practical question. So let me
turn things around an describe what I do currently and ask how a DWARF
producer/consumer working together should do the same when using a
default location list entry.

Currently when a user wants some information at a given location a
consumer might look up the inner-most program scope DIE for that
location and from there works out which variable/arguments are in scope
that the user might be interested in. If such a variable is described by
a location list the consumer can search the valid ranges and if the
location address falls inside one we can present the user with the value
of that variable, otherwise we can tell the user that at this location
the value of the object is not available. The idea being that producer
and consumer work together so that a user doesn't get invalid
information about the value of a variable/argument. Which might be
particularly confusing if the consumer is a non-interactive tool like a
tracer/profiler and the user only wants some statistics on valid values
encountered during some run.

Assuming the consumer is interested in "the object is not available for
the portion of the range that is not covered" property of the location
list then it looks like if the producer uses a default location list
entry that information is no longer available. Because a default
location list entry describes both the duplicate valid ranges and the
invalid ranges at the same time.

So if a producer wants to take advantage of a default location list
entry to encode a smaller location list for an object, then how should
it present to the consumer the same "not available" information?

Thanks,

Mark