On Feb 23, 2017, Michael Eager <ea...@eagercon.com> wrote: > Please submit comments/proposals online at http://dwarfstd.org/Comment.php.
> It greatly helps to specify the sections and pages that you propose > changing, as well as the text changed, added, or removed. Thanks, will do. I guess I will need some more discussion here, before having a concrete proposal, though, because of some changes prompted by changes in loclist in DWARF5. E.g., instead of what I had suggested, namely a separate attribute: >> A DIE with a DW_AT_location list may also have a DW_AT_locviews >> attribute referencing a viewlist table. and a separate list with matching entries for each loclist bounded location description entry: >> For each range in the location list (not its terminator), the viewlist >> should contain a corresponding pair of entries, one corresponding to the >> views that start and end the range. Each view is encoded as a separate >> uleb128 quantity. we could have: 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. I had hoped the newly-introduced entry kind identifiers could help accomplish this, but AFAICT it doesn't: a consumer wouldn't know how to skip an entry of an unknown kind, so adding any extended entry kind would make the location list unusable from that point on, and consumers might be well-justified to disregard the whole thing. 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. With that, I'm leaning towards sticking with a separate attribute and viewlist form, as proposed before, in spite of the awkwardness of the matching list entries, instead of trying to fit the view numbers in extended loclist entries. Now, of course, if this becomes part of the standard, it might make more sense to encode the view numbers in the location list, even if it would make location lists of this new version of the standard incompatible with location lists of earlier versions. 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? Thanks in advance, -- 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
