On Mar 9, 2017, Alexandre Oliva <aol...@redhat.com> wrote: > a. a new kind of location list entry that specifies a pair of view > numbers, that must be placed e.g. right before a bounded location > description entry,
> b. several new kinds of location list entries, each corresponding to an > existing bounded location description entry kind augmented with a pair > of view numbers > Now, my intent has been to make this extension backward-compatible, so > that debug info consumers unaware of view numbers can still use the > location lists. > Is that so? If loclists are really not supposed to be experimentally > extensible, introducing a new experimental kind will be a bit of a > challenge, even if it is proposed or even accepted for inclusion in > future versions of the standard. > So, before I elaborate either form, I'd appreciate feedback on which > would be the preferred way to introduce this sort of extension: > introduce new loclist kind or kinds, in spite of breaking backward > compatibility of lists, or use a new attribute and list form to hold > view numbers? I got some private feedback suggesting I'd be better off proposing for DWARF6 an extension to loclists, rather than a separate attribute, and perhaps also some way to extend loclists in backward-compatible ways. The latter is easy (as described in a. or b. above), but I'm having trouble convincing myself that the latter can actually be done in a sensible way. We could have something in the CU that specified how to skip nonstandard loclist entry kinds potentially used in the CU's loclists. I envision a few possibilities: specify the expected length of an entry kind in the CU as a fixed quantity of bytes, or of leb128 values (interpretation of uleb or sleb is up to the reader), or have each entry start with a length. Supporting all of these possibilities wouldn't be too hard, and I can imagine uses for each of them, based on existing entry kinds and on the view range extension I'm designing. However, I can hardly imagine that a per-entry length would ever be used: it wouldn't be very compact; such an entry kind would probably not be standardized with an explicit length, so it would be forever a nonstandard extension; and an indirection layer could make an explicit length specification redundant (but then again it probably wouldn't end up being standardized that way). So, it would seem like we could make do with fixed-length extensions, but even those could be introduced through additional attributes, rather than as parts of loclists. But then it hit me: the indirection layer mentioned above could help us do away with even such fixed lengths: what if we had an entry kind that added, to the present loclist, entries from another loclist, starting at the entry whose address/offset is named, until its end-of-list entry (or an unsupported entry kind) is reached? We could then use this to factor out shared entries from loclists, and also for nonstandard extensions (a reader not acquainted with them would just take the unknown entry type as the end of the (sub?)list. So now this renders the notion of CU-specified fixed-length extensions redundant, and extensions can become standardized without encoding changes, they just cease to be potential loclist-terminating entries once they become part of the standard. Given this, does anyone see any reason to still propose fixed-length extensions "reserved" in the CU, as I described before? Conversely, does anyone think we'd better not support extensions to loclists whatsoever, not even through the "factoring" mechanism I described above, and resort to additional attributes to experiment with loclist extensions instead? Thanks in advance for any feedback on these matters, -- Alexandre Oliva, freedom fighter http://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist|Red Hat Brasil GNU Toolchain Engineer _______________________________________________ Dwarf-Discuss mailing list Dwarf-Discuss@lists.dwarfstd.org http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
