[Dwarf-Discuss] Default Location List Entry Issue 130121.1

[Michael Eager]

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