[Dwarf-Discuss] Default Location List Entry Issue 130121.1

[Mark Wielaard]

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?

Thanks,

Mark