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

[Alexandre Oliva]

On Mar  9, 2017, Alexandre Oliva <aoliva at 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