[Dwarf-Discuss] Default Location List Entry Issue 130121.1
eager at eagercon.com
Wed Apr 23 06:54:35 PDT 2014
On 04/23/14 04:46, Mark Wielaard wrote:
> On Tue, 2014-04-22 at 10:07 -0700, Michael Eager wrote:
>> On 04/22/14 03:57, Mark Wielaard wrote:
>>> 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?
>> I think that this is an unusual situation. Can you describe when this
>> might be the case?
> I think it is not such an uncommon situation. When a compiler inlines
> part of a function somewhere else that often seems to create interesting
> ranges and locations. My first search for an example immediately showed
> up something that I think covers this situation. It was in the debuginfo
> for bash build with gcc 4.9. The function parse_shell_options with a
> variable is inlined into main. That variable then gets the following
> location list:
> [ 1bec] 0x0000000000420ce2..0x0000000000420d29 [ 0] reg15
> 0x0000000000420e25..0x0000000000420e33 [ 0] reg0
> 0x0000000000420e33..0x0000000000420e52 [ 0] reg15
> 0x0000000000420e66..0x0000000000420e74 [ 0] reg0
> 0x0000000000420e74..0x0000000000420e7d [ 0] reg15
> 0x00000000004211ba..0x00000000004211df [ 0] reg15
> 0x00000000004211e7..0x0000000000421217 [ 0] reg15
> 0x0000000000421252..0x0000000000421267 [ 0] reg15
> 0x000000000042129b..0x00000000004212b8 [ 0] reg15
> 0x000000000042137d..0x0000000000421385 [ 0] reg0
> So some of the ranges "connect" and just describe the variable location
> in different places, but there are also some invalid ranges where the
> location is clobbered/unknown. I imagine a future DWARF5 producer might
> want to use a default location list entry using reg15 because most valid
> ranges use that location. That would make the location list much shorter
> but also looses the "not available" information for the consumer.
>> The most reasonable thing to do is not generate a default location.
>> If there is no default location which applies at all addresses which
>> are not specified in the location list, then generating a default
>> location doesn't make much sense.
> Yes, I guess that is the most reasonable thing in the above case.
>> An alternate might be to include a location list entry for the range
>> where the object is not available and have that contain a zero-length
>> location list. That would be non-standard, but I think that any
>> consumer would reasonable interpret this as location not available.
> That could work. It just needs a bit more work on the producer side to
> know whether using a default location entry plus filling in "the
> gaps" (and start and end range) results in a smaller location list.
> Could that be made into "standard behavior" and recommended as best
> practice when using a default location entries?
The best practice is to use the default location list entry as it was
intended and as documented.
Michael Eager eager at eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
More information about the Dwarf-Discuss