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 _______________________________________________ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
