On Wed, Jun 30, 2021 at 5:37 AM Mark Wielaard via Dwarf-Discuss <
dwarf-discuss@lists.dwarfstd.org> wrote:

> Hi,
>
> We discussed 170427.3 Extending loclists with common sublists in the
> last meeting. http://dwarfstd.org/ShowIssue.php?issue=170427.3
>
> This issue was original part of a group of proposals to introduce
> Location Views. Location views allow the user to observe multiple
> program states at the same program counter. It would allow a user to
> see that one instruction does various state changes expressed in the
> source program that the compiler optimized into one instruction (for
> example increment a variable in two steps in the code, which the
> compiler would optimize into one step). Having multiple views makes
> having similar location lists more common and/or makes it necessary to
> mark those location lists as part of a particular view. But having a
> generic mechanism for having common sublists seems useful in general.
>
> This particular issue was split in two because it originally described
> two mechanisms, one to extend loclists with user defined operations,
> which became http://dwarfstd.org/ShowIssue.php?issue=170427.2
>
> This proposal deals just with introducing two new operands
> DW_LLE_extend_loclistx and DW_LLE_extend_loclist. One extends the
> location list with to content of the loclist from the given index, the
> other uses an offset into the loclists section.
>
> There were various comments on this proposal:
>
> - The original proposal imagined unknown loclist operations would
>   end the current location list. Having such an implicit action on
>   any unknown operation seems unwanted. So it was proposed to delete
>   the part of the proposal.
>
> - We like to keep the operands of loclists and rangelists the same.
>   And if it is useful to construct loclists from common sublists, it
>   seems it would be useful to construct ranges from common subranges.
>   Add the same operands to rangelists.
>

For what it's worth - I can see at least a plausible motivation for range
list extension: It's not uncommon for the ranges of a parent DIE to consist
of the union of the ranges of the children where there may be no ability to
form larger more contiguous ranges in the parent (that would be a more
compact representation), for instance with LLVM's "basic block sections"
each function/subprogram may have DW_AT_ranges, and the CU's DW_AT_ranges
would be a matter of listing all the subprogram ranges. So including the
subprogram ranges into the CU ranges rather than repeating them could
provide some savings - I'd like to see data on how much of a difference
that makes (so at least a prototype implementation) before deciding whether
it's a worthwhile feature to add.

But I don't know of a similar use case for loclists - so I'd want to see
some more motivation (as discussed below, maybe it'll become apparent with
more view numbering functionality) before going ahead with this. (though if
the rnglist case is motivating enough, I wouldn't object to equivalent
loclist functionality just for symmetry even without a solid use case)

Wording wise: The indexed version probably needs wording that loclists_base
must be specified on the CU that references any list that uses the indexed
version. (Maybe it'd be preferable to have some wording that the indexed
version can only be used when referenced via an indexed form? That way you
couldn't end up with weird sharing cases - where two CUs both reference the
same list? (Hmm, actually I'm not sure that's true - maybe two CUs can
technically have the same loclists_base?)). The sec_offset based version -
seems maybe OK that that could lead to sharing directly or indirectly (eg:
two CUs using two separate rnglists that each include some common rnglist).
Though maybe best to disallow this if it isn't already - now that rnglist
contributions have headers, perhaps we could/intend to restrict things such
that each contribution is unique to a single CU and a CU can only reference
rnglists within that contrtibution? (so there's no intent to support
sharing rnglists between CUs)


>
> - It seems more natural to call this include instead of extend.
>   So rename DW_LLE_extend_loclistx and DW_LLE_extend_loclist to
>   DW_LLE_include_loclistx and DW_LLE_include_loclist.
>
> - Maybe add a note that creating loops with sublists including each
>   other is not allowed? Seems obvious, similar to some other constructs
>   in DWARF that could create a loop. Not sure if it needs to be
>   explicitly spelled out here.
>
> - It isn't really clear if this is needed or is actually an
>   optimization without dealing with location view numbering first.
>   So it was decided to revisit this issue (with the above changes)
>   after we reviewed that proposal:
>   http://dwarfstd.org/ShowIssue.php?issue=170427.1
>
> Attached is the updated proposal with the above comments incorporated.
>
> Cheers,
>
> Mark
> _______________________________________________
> Dwarf-Discuss mailing list
> Dwarf-Discuss@lists.dwarfstd.org
> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
>
_______________________________________________
Dwarf-Discuss mailing list
Dwarf-Discuss@lists.dwarfstd.org
http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org

Reply via email to