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 ea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306 650-325-8077
_______________________________________________
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
