[Dwarf-Discuss] implementing SFN, support for multiple views per PC

[Alexandre Oliva]

On Feb 23, 2017, Michael Eager <eager at 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